Jeff On Games

My good friend and educator Bill Crosbie is asking some tough questions on Twitter, specifically about what to teach fledgling game programmers to make them the most marketable to game companies when they graduate. Now, you might not be able to tell from the Twitter conversations, but Bill is actually very concerned about giving his students a good, foundations based, computer science education, while also giving them the opportunity to make games, and giving them skills that they can immediately transfer into the workplace, all in less than the two years he happens to have them. And what he's asking are actually really hard questions, and got me thinking: What would I want out of programmers coming out of two year and four year programs, both those that are focused on game development, and those that aren't? What can I tell Bill to do to make sure that I would at least consider hiring his better students?

The Never Ending Conflict

This comes down to a never ending conflict that educators are well aware of: the conflict between giving a student marketable skills, teaching them the tools and technologies that are relevant "right now" that they can put on a resume and will immediately generate hits on job search websites, and giving them an actual solid education in computer science and software engineering. Ask most programmers in the game industry (at least the ones I know) and they will tell you the later is more important, but look at who actually gets hired and the former plays a very obvious role. The problem is that when I'm hiring a programmer, I want someone who's smart and gets things done, but I also don't want to take the time to teach them all of the skills that they're going to use on a daily basis. It's a tough balance, and getting programmers that don't understand things about your core technologies, or at least their underlying principles, can be dangerous.

In addition, technologies go out of date so fast that teaching one specifically can be counterproductive. C++ has been the de facto standard in the game industry almost since inception, as we've needed the control and power that C++ provides, but the technology that we're working with under the hood can dictate exactly how we can use C++. Students taught to think about single threads of execution on x86 processors, using primitives that would be perfectly fine in other industries (like stl vectors and strings) would be screwed in today's game industry, an industry which is (now) all about squeezing as much performance as possible out of multiprocessor, multicore systems on x86, x64, PPC and Cell chipsets. And interestingly, this is exactly what's happened. Students taught to think ONLY in an object oriented paradigm have trouble parallelizing their code and thinking in terms of small executable chunks that don't suffer from things like race conditions and cache misses, if they even know what those are.

But what's academia to do? Most game developers won't even look at a programmer unless they have C++ experience, understand OO concepts, have done at least some work in DirectX, OpenGL, or Win32 programming, and has as a significant portfolio of work. This leaves professors looking to help game industry hopefuls little time to discuss things that are essential to computer scientists, like the benefits and pitfalls of functional languages, strong and weak typing, lazy evaluation, early and late binding, combinatorics, state machines and automata theory, synchronization patterns (semaphores versus critical sections), common concurrency issues and how to avoid them, and even compiler and virtual machine theory. Even if they get through all that theory, how many schools will be able to talk about the inner workings of modern chipsets, cache coherency, synchronization primitives, compiler intrinsics, and virtual memory? If you're a recent college graduate that can actually give me a definition on all of those terms, explain how they're relevant to modern computer software and game programming, and has a fundamental understanding of any modern game API, you're way better than I was when I graduated, and maybe better than I am now because I'm not sure even I could do it. And I can't tell you how much of it is important to know when you graduate, and how much you can learn either on the job, or on your own. Even the IGDA curriculum framework lists so much stuff that it would be almost impossible to push through in a 2 or even 4 year program. You have to pick and choose.

So if I can't figure it out, what's an educator supposed to do? Take a best guess I suppose. Fundamentally, though, I think they need to teach what colleges and universities have said they're teaching for years.

Teaching How To Think, How To Learn, and How To Work With The Tools

Most liberal arts colleges and universities still say they teach their students how to think. They're not necessarily teaching skills, and I like that. That's what I want from my programmers: I want them to know how to think, and, more importantly, how to learn. But there's nothing that says that this must all be done with theory, or that it should be done purely with theory. In my mind, the problem is that Computer Science and Computer Game Programming programs come out of science and math programs, and follow their pattern for how to structure classes: either 3 credit classes with focused homework assignments with little to no cross class application, or 4 credit labs where a single lab is considered enough to create a program that demonstrates theory. This is not only not enough time, but it doesn't encourage long examinations of hard topics, it doesn't encourage learning by failure, and it doesn't encourage learning why it all works the way it does.

How many schools actually look to the art world for inspiration? In most art schools, you have 3 credit studio classes, which last actually 6 to 10 hours per week, have only 2 to 3 projects per semester, and are combined with classes on fundamentals that can help improve project work. I don't think I ever had a class structured this way during my computer science education. The closest I ever got was a Software Engineering class, which wasn't really about software engineering as much as software planning, which is completely different. But, for programmers, these project classes should not necessarily be introducing new technology. At least at the start, students should work from the base competencies of whatever the school was teaching the previous semester, and early project classes should expect failure (though not say this out right), and encourage students to spend several days at the end of projects to examine their work for flaws in their design and flaws in their process, not flaws in the final product. This is where we teach students how to learn, and how to find the problems in their own work: by screwing it up royally.

In addition, I feel that early theory classes should be kept separate from those that are teaching applications of programming, especially those that are focused on programming in specific languages. However, the two classes should be linked together and move in conjunction. Each class on algorithms and data structures should be paired with the class that teaches its specific application to the language they're working in, thereby teaching both programming and theory. This I think is the major failing of most CS programs. They teach programming, usually in a specific language, and expect the students to pick up theory on the way. In the worse cases, the students return later to have classes specifically on theory, which is sometimes a repeat of what they already learned, just presented as theory instead of a feature of the specific language. By making that clear separation of learning theory and learning practice in two separate but joined classes, your students should progress faster in both. It also creates a flow in teaching and a reason to move to languages as you progress. When theory classes are ready to introduce things like how memory works, caches, cache coherency, pointers, and the like, that's when you can move your classes on programming into teaching C++. As you learn concepts in functional languages, you can start teaching ML in programming classes. As they learn the theory, they can see how it was applied in the language they're learning.

Finally, by the end of any given program, students should be spending a majority of time in studio classes, working on projects that utilize everything they've learned with frequent review of architecture and progress from their professor. However, this should be supplemented with theory classes that go beyond what they'll need to use on simple projects, like topics in programming languages, lexer / parsers, and the ability to prove algorithms correct, and include seminars in currently relevant technology and concepts (guest speaker series are great for this).

Doesn't Answer The Question

Interestingly, I'm not sure if this actually answer's Bill's questions, but it gets a lot of thoughts off of my head. I actually had an entire set of semester plans that went with this post, but scrapped it when I realized I have absolutely no experience in that regard. I can tell you what I want, which is basically separate theory and practice classes joined at the hip in early stages, followed by advanced topics in CS and software engineering paired with Studio classes. But, for me to tell you exactly how those classes should be structured doesn't make any sense.

So hopefully, without answering the question, I've been at least a little helpful.

I apologize for being quite silent on this blog recently. I've been super busy with work, personal projects, and my new blog, the Toolsmiths. In general, I'm super excited about the success of the Toolsmiths. We've been hit on reddit twice (with HUGE traffic spikes both times) and the comments have been generally excellent. I'm hoping that the momentum will continue straight into GDC, when I'll be hosting the Tools SIG roundtable to discuss the various ideas for the direction of the SIG in the coming year. The blog was a great start, and I think it has gotten people excited about the Tools SIG again by making it visible. Now we need to leverage that into community projects that can actually help the community.

As a side note, I can really only act on all of these plans if I'm elected Tools SIG chair. If you haven't voted yet, please remember to vote soon, as elections close on Friday.

In addition to the Toolsmiths, I've been working on some small side projects, including a port of Sort to XNA, and a port of Angel to XNA. I know a lot of people are interested in the Angel port, and so far it's coming along very nicely, though it does have a lot of differences from the original Angel (especially in the rendering department, obviously). Hopefully I'll have my first alpha for that available after GDC, but we shall see.

So, if you haven't noticed, this blog has been a little quiet recently.  It's not because I don't have a lot to say, but because I haven't had the time to say it.  One of those reasons for that is because I've been spending a lot of time working with the IGDA Tools SIG (which I've talked about before) to launch a new collaborative blog: The Toolsmiths!

The new blog has two other great authors, Geoff from Insomniac and Dan from Robotic Arm Software.  I'm really looking forward to the content we'll have over the next year or so, and I hope anyone interested in game tools will take some time out to read our posts.

My first post, on continous integration and build systems, will appear on Wednesday.  Hope you enjoy the new blog!

This weekend, I was fortunate enough to attend (and present at) Boston Gameloop. I was fortunate enough, partially, because it was co-organized by my boss, but that's beside the point. I presented two sessions, one on distributed version control (which I gave twice), and the other was a co-talk with me and IF luminary Andrew Plotkin about agency / complicity in games. I'm hoping someone took notes at that talk because I think it was pretty awesome, and being able to basically have a public discussion about agency / complicity with Andrew was pretty awesome. In addition to presenting, I was able to attend talks on implied ethics in game rules, see some demos / a presentation on dynamic animation of virtual actors, and spend a little bit of time in a round table on Scrum, all of which was awesome.

So all in all GameLoop was definitely a great experience, and props to both Darius and Scott who organized the whole thing. I'm looking forward to the conference occurring again next year!

Hot on the heels of me praising the Xbox Live Community Marketplace comes this opinion piece on Gamasutra that's actually fairly angry at Microsoft's practices in this regard. I definitely see his problems with the promotion thing, but almost everyone did. That was the single most asked question at GameFest, so I'm sure you'll see a change in policy about it before the fall launch, or probably very shortly after. The exchange rate issue is… interesting… to say the least, but that said, I can see how it's very difficult for Microsoft to track how points were purchased and in what country. I'm sure it hurts foreign developers a lot more than it hurts Americans though.

So, although I think a few of Ron's complaints are understandable, I think he's missing one key component of the XBLCM vision: lowering the barrier for entry so that anyone can make games for a console. As I pointed out in my last post, this is the first time any console manufacturer has ever done this, so, obviously, they may get a few things wrong. The comparisons to WiiWare / PSN I think were completely misplaced here, since hobbyists can't actually develop for those platforms without hacking around the systems. Even then, both Nintendo and Sony have tried to stop such hacks, effectively attempting to close off their console as much as possible.

So I think Microsoft took a very brave step in the right direction. Not only that, but I think it's WAY more than what most hobbyist / community game creators were expecting. To have their games "published" on an actual console, with potential for pretty large returns. I can understand the backlash from indies, since once you have a budget you can get shafted from the XBLA point of view, and price caps, royalty and exchange rates may hurt your actual prospects as a developer, but, honestly, look at this for what it is: a very positive move for creating a new caste of developer who have no budget, no team, and a desire to see their own game on a console, and maybe make some money while they're at it.

If you have problems with the rest of the system (which you should), that's something between you and the XBLA team. I feel pretty good about XBLCM.

So, if you haven't heard, Microsoft announced at GameFest that they'd be deploying a new community market place this fall on the Xbox 360, and that developers will be able to keep (up to) 70% of the revenue generated from games on the community marketplace. While not unexpected, this is pretty huge news.

Before getting on to commentary, I'd like to quickly point out how revolutionary this whole set up is. This is the first time in my knowledge that a major console company has actively encouraged (or even allowed) development on a retail console at any price (Sony had a version of the PSOne you could develop for, but it was not a retail kit). In addition, this is certainly the first time that any console manufacturer has encouraged a community in which to share those games (the Creators Club) and even more importantly, this is the first time a console manufacturer has created a marketplace where anyone can download created games and anyone can make money off of those games. Even with the fact that you are limited to a .NET sandbox, this is pretty huge, and I'm pretty excited about it.

That said, when Community Arcade was announced, and later when they announced Community Marketplace, I was nervous, though I couldn't figure out why. It struck me when I was at a game store over the weekend. There are a lot of freaking games out there now. A ton. And, honestly, 90% of them aren't any good. There are also a lot of XBLA games, and, honestly, about 90% of them aren't any good. With Community Arcade/Community Marketplace, you can be sure 99% of games on there won't be any good. It makes it really hard and frequently frustrating attempting to find those hidden gems that really make it all worth it. Certainly, community reviews, Metacritic, and similar sites help find games, but what do you do for those games that are fringe (and therefore generally ignored or given low Metacritic and community scores), but awesome? Certainly the viral aspects that Microsoft is putting in (send this to a friend and, hopefully, a rating system) will help, but even then many fringe games get overlooked because there's just too much else coming out right at the same time. I just hope that the game industry isn't a victim of its own success, having so much content that none of it makes any real money.

Regardless, I'm not sure it's an actual issue. You can be sure I'm already working on XNA prototype games. I'm not going to miss this opportunity.

So, I'm generally disappointed in the state of game journalism and game criticism, but I won't talk about that too much today. It's been harped on by people far more eloquent than me and I don't think it needs to be reiterated. However, last night I got a copy of this month's Game Informer (the one with inFAMOUS on the cover) and I have to say I'm really, really disappointed in one of their articles, one that could have been used to actually provide critical insight into games that both gamers and game developers put up on a pedestal for whatever reason. The article is their Second Annual Sacred Cow Barbecue.

Now, normally, I'd be all for this, but literally, here's their list of Sacred Cows and a basic summary of their complaints about each game:

• Chrono Trigger: The plot is cliché and unbelievable. To quote the article: "Chrono Trigger proves that RPG dorks will buy literally anything, just as long as it's Japanese and doesn't make a lick of sense."
• GoldenEye 007: The graphics suck and the controls are bad (compared to current dual analog controls).
• Gran Turismo (series): It's too realistic. They also didn't like the career mode and lack of online play.
• ESPN NFL 2k5: It's put on a pedestal only because EA stole the rights to all NFL games. It's no better than Madden.
• Half-Life (series): The plot sucks and Gordon Freeman isn't an interesting character. To quote the article: "For a series that's been praised for its great storytelling we sure as hell can't make head or tails of this convoluted collection of sci-fi drivel." Also, no online pay "that's not Counter-Strike or an addon pack," and a one line complaint about physics puzzles.
• Super Smash Bros. (series): All of the game's characters are Nintendo has-beens. To quote the article: "… there are [only] a few characters … that have sold a game in the last 20 years". Also, the game doesn't necessary require skill to win.
• Rez: It's a standard rails shooter with a derivative visual style (of Batlezone and Tron according to GI), derivative gameplay (of other rail shooters) and derivative soundtrack of "generic techno music that even superstar trance hacks like DJ Tiesto and Paul Oakenfold would be embarrassed to spin."

Okay, as a challenge, I'd like my readers to find the actual design flaws that GI points out in any of these games.

Go ahead I'll wait.

That's the thing, GI fails (with the exception of possibly its complaints about ESPN NFL 2k5) to point out any actual design flaws in any of the games it attempts to knock off its high horse, even though every single one of these games has design flaws that can easily suggest that it is over-rated in one way or another. Faulting Gran Turismo for being too realistic or faulting Super Smash Bros for (essentially) implementing rubber-banding mechanics is like faulting comedies for being funny and tragedies for being sad. Faulting Golden Eye for looking like crap compared to modern games or for its bad control scheme compared to the dual analog sticks is like faulting "It's a Wonderful Life" for using old styles of directing and cutting, or faulting pre-Citizen Kane movies for not using post-Citizen Kane conventions. It misses the point of why the game is good in the first place.

If you want to write an article like this, and if you want to actually be taken seriously as a game critic, maybe you should actually think critically about the game instead of finding very small quips that don't actually affect the game in any reasonable way. Chrono Trigger is not considered amazing because of its plot, but because of the way the plot unfolds, the open ended section at the end of the game, and the amount of freedom you're given within the linear plot. Half-Life, similarly, isn't necessarily considered amazing for its story, but for how that story is presented, and how the designers worked around the fact that your character shouldn't talk (as that would break immersion).

And don't even get me started about their complaints about Rez. Faulting each individual component of that game is like faulting a hot fudge sundae because hot fudge and ice cream aren't actually interesting on their own.

Honestly, I feel like this article was simply meant as flame bait, and I'm almost sorry I felt the need to fan the flames. That said, GI is (according to their cover) "The World's #1 Computer & Video Game Magazine" and I wish that I could at least expect that magazine to publish something a little more insightful than what you can get on their forums every day, but I guess that's asking too much.

(Note: The whole point of this post is to get you to join the IGDA Tools SIG, but I don’t get to that until below the fold, so I’ve decided to just push it up front here for those of you that don’t feel like reading my long tools rant. So, instead, please just go join here)

I’m a firm believer in tools.

I actually believe that good tools, provided both internal (from actual tools departments) and externally, are key to the success of any software development company, but especially game companies. I would go so far to say that 80% of any programmer’s job in a game development company is, or at least should be, making tools that make artists, designers, and other programmers happy. These are your engine programmers. They do good work, and they’re very important.

However, there should also be a good number of your programmers who’s *only* job is to keep your artists, designers, and programmers happy. These are your dedicated tools programmers, who do nothing but code and fix tools and process all day. If you don’t have these people, you’re missing out. Why? Think of all the places tools touch, or should touch, in game development and process that don’t actually involve working with your engine.

First, everyone benefits from a good build pipeline. Whether you’re doing continuous integration or not, having fast turnaround on art and code changes is always a good thing. Additionally, if everyone can grab changed assets quickly from central servers, that means work can get underway faster in the morning. The tools to do these types of things are usually available, but if you think an engine programmer (or worse, a producer) is going to go find them you are sorely mistaken. Of course, having that good build pipeline means also having good source control, and usually means having good integration between your source control and your tools for creating and exporting assets. And here, there aren’t usually tools available to you. You have to make them yourself, but the jump in productivity from this type of integration is enormous.

Additionally, programmers need tools themselves, but only the select few will think to make them, and usually only for themselves, on an ad-hoc basis. Deployment scripts, revision / code review change scripts, Visual Studio / WinMerge integration; these are all tools I’ve seen created by fellow programmers at game studios that never get passed around. But even then, there are tools that are incredibly useful that an engine programmer might never get around to. Memory inspectors, automatic bug reporters (and potentially bug collators), output filtering systems, external debug consoles, formal logging / metrics. All of these things are useful for programmers (and, in the case of formal logging, designers), but very few have (or will take) the time to really look into them as possibilities. Not My Job Syndrome.

Lastly, dedicated tools programmers have the time and ability, to keep up to date with the latest tool releases and technologies that people are using for tools in the game industry. This is key, because new concepts (like monkey testing, automatic crash reporting, formal logging / metrics, uses of XML / XSLT) pop up every day, and sometime lead to enormous gains in productivity. Without the time to look into them, engine programmers tend to lean on old technologies, with the “It’s not broke, don’t fix it” mentality. This is dangerous to your productivity, since sometimes it is broke, and your programmers just don’t realize it.

Now, if you feel like I do, or you want to learn more, I highly recommend joining the new(ish) IGDA Tools SIG. The SIG is dedicated to staying on top of best practices for tools development, posting about new tools that are becoming available, and hopefully (eventually) being a great educational and discussion resource for tools developers. If you are interested, I urge you to join. You will not regret it.

So a little while back I asked for your questions on the game industry. Bryan was kind enough to ask two very good questions, both of which are almost too advanced for a breaking in FAQ, and I felt were too important to be pushed to a comment, but they deserve answering, and I apologize for waiting this long to answer them.

The first question:

Some developers cite 60 hour, 6 day a week schedules like they are trying to drive people away from the industry. They speak as if this is acceptable and that only those with true passion for the work can hack it. Am I ignorant in thinking that someone - passionate or otherwise - could not possibly sustain quality output under these conditions? Is this an accurate snapshot of the industry?

This is a hard question to answer. At times, Bryan is absolutely right: it seems like developers cite their long hours in order to drive people away from the industry, and sometimes seem to wear their long hours and tough crunches as "badges of honor" (as one developer I know put it). This is a shame, as it drives perfectly talented individuals away from the industry.

But the question is, is this reality in the game industry, and I'm afraid that the answer is yes, especially if you are new to the industry. Though you don't work those hours constantly, crunches can be pretty brutal, and can last for quite a long time (depending on the company and the game). There's definitely a reason that the game industry has something like a forty percent burn out rate within five years. Think about it. That means if you're sitting in a hall of developers new to the industry, look to your left, then look to your right, one of those people will not be in the industry in 5 years.

However, I will say that many companies and individuals are trying to correct this. Any company that has a CEO or lead developer on or active in the IGDA Quality of Life SIG is one where these types of hours will not be the norm. Some studios that run scrums do so because they want to avoid long periods of crunch. But, understandably, sometimes these studios are hard to get jobs at, because they attract some very talented individuals that understand, like you do, that these types of crunch to more to hurt productivity than help it. However, if you can join a company that knows how to avoid crunch, balancing the rest of your life becomes fairly easy.

As a final point, I will say that you absolutely need some sort of passion to be in the game industry, though not necessarily for games (you can be passionate just about writing really clean SPU code like some people I know), and not necessarily because of the long hours you’re going to have to work. Really, you need passion because 90% of the work in the game industry is just as tedious and monotonous as work in other high tech disciplines, except that your pay will be lower, your benefits will be lower and customers tend to be pretty ruthless. If you can ignore all of that, working in the game industry is pretty damn awesome.

The second question:

How does it start for most developers? Specifically people today. Obviously we have not been making games for our Commodore since we were 8. Do most come from other disciplines with experience in related fields? Are most newbies (to the industry) today fresh out of college, eager to show their talents?

So, interesting story. I’ve been talking with my co-workers and other Boston game industry people for a while and they like telling stories about some of the geeky things they did when they were younger (from programming to electrical engineering, to whatever). Now, I’ve always been interested in games, but I didn’t really get into programming until late high school, and I didn’t really make a game until college. So, I’m evidence that you don’t necessarily have to program the Commodore since you were 8 to become a productive member of the game industry. That said, I wish I had some of those stories (a failed RPG maker game is about as cool as my stories get).

However, now more than ever, you have to start looking early for game industry jobs, because entry level jobs become more and more rare as time goes on. When you hit college, you should start networking, get to know people, and start feeling your way around the industry. Additionally, start making games, and (if you can) find other people to make games with, especially if you’re not at a college or university that has a games program (this is common advice that I give to everyone). If you wait to start networking and wait to start actually making games, it will be harder to find a game industry job as a “newbie.” If you take a job elsewhere, you’ll find it hard to make the time to make games after college, and, even if you do, you may find it harder to adjust to the inevitable pay drop (note this pay drop is programmer centric, artists I’m told get paid very well in the game industry compared to other industries). Basically, the idea is to take the time when you have it (in college) and take the risks when you’re young. Show that you are interested in the game industry early. By waiting, you just make it harder for yourself.

Hopefully that helps with your question. If you have any more, please feel free to post them!

The 2007 Game Career Guide issue of Game Developer magazine is out, and a nice digital version is available for download. I actually wrote one of the articles for this in the Top 10 Tips section for programmers looking to get into the game industry. Now, the tips in the guide are pretty generic, and really aimed at a high school / starting college demographic. However, if you're in that audience I totally suggest you give it a read. It can only help.

When I was writing the tips, I actually thought of a whole bunch of others that I wish I had known just coming out of college and looking for a game job (or when I was looking after a year as a government contractor). I thought about putting these tips in, but they were really for a completely different audience (namely, me 3 years ago) and partially politically charged. So, I left them out, made the article advice more focused and generic, and decided when the article came out I'd post the other tips to my blog. They make better blog fodder anyway.

So here’s a few tips for those of you that are about to take that first job in the game industry. This is from personal experience and a few years of misery in the game industry, and it should all be taken with a grain of salt.

1. Know you development style, and know the company’s as well. Before you commit to working for a company, know how they work. If you’re a stickler for process (like myself) make sure you know whether the company you’re about to work for is as well, or if they’re willing to adjust to become so. If you’re more the “get things done” type, besides being doomed in the long run, you shouldn’t go to work a place advertising that they’re full agile, full XP. Granted, working there might do you some good.
2. Don’t undersell yourself. Money isn’t everything, but being underpaid really sucks, regardless of nebulous bonuses that are promised (Note: I was underpaid in the IT world way before I went into the game industry, so this really applies across the board). Know what other people are making in the industry in your area. Know what you’ll need to live comfortably on, and know how skilled you are. You’ll be thankful later.
3. Always improve. After you get your first game job, don’t think you can coast around on easy street. Don’t ignore new technologies coming out (outside of games too guys), because you never know how much you could improve things at a company just by paying attention to advances in things like .NET and database development
4. Know what you’re getting into. Make sure your significant other knows too. Crunch sucks. And it’s almost everywhere in the game industry. Avoid places that have horrible crunches (very hard) or make sure your significant other knows that there will be months at a time where you might not see each other. It’s sad, but a reality.
5. Know the company’s stance on conferences. If you’re the type of person that likes going to GDC and likes talking at GDC (like me), know whether your company will allow you to do that. Also find out what they’ll reimburse you for, and what they won’t. You don’t want to find out a month before GDC that they don’t want you going. That just sucks.

Now, this advice is kinda slanted toward people that have a lot of confidence in having a lot of offers in the industry (which doesn’t happen often), but following this advice will at least let you know what you’re getting into before you jump in and become miserable.