Thursday, July 02, 2015

On the Relative Importance of Aleister Crowley

Every once in a while, it becomes super popular in various groups of occultists to argue about Aleister Crowley. In the OTO and A.'.A.'. groups I interact with, the debates usually boil down to ways people make it ok to be a Thelemite even though he was a bastard who got some things terribly wrong overall.

Outside his cultus, people argue about how important he is to modern occultism. Jake Stratton-Kent and I were talking about it the other day on FaceBook. He doesn't think Crowley was the greatest magician ever, and I agree. Not the greatest ever, but certainly the most influential of the last 1500-2000 years, within the modern western mystery tradition.

I personally believe that less than 1% of English-speaking modern occultists are untouched by Crowley. Every system of magic in the English-speaking West finds its way back to To Mega Therion at some point. Even systems that think Crowley is shit still go to pains to differentiate themselves, and thereby define themselves using Crowley's teachings and methodologies. So even when people hate Crowley, he's still influencing their practice and their minds.

But that said...

Who gives a fuck? There's nothing Crowley wrote or taught or learned or changed or presented that is necessary to accomplish "the Great Work." People did it for years before he came along, and people will keep doing it long after he's gone the way of Buddha, Moses, Christ, and Mohammad.

In the mean time, if you read his stuff and it resonates with you, enjoy it. If it doesn't, do something else. There's nothing any Order he created, changed, influenced or destroyed on the planet that has anything in its teachings that you must receive from that group to accomplish the Great Work. The Golden Dawn, OTO, and A.'.A.'. are not the only way to the Philosopher's Stone, and for a lot of people, they will hinder your progress more than help.

So many times when I see people bashing Crowley, it's to make themselves look smarter or more important in comparison. I can count on one hand the number of magicians I've met who criticize Crowley who have actually read his works and understood the intent of his practices. Jake Stratton-Kent and Jason Miller pop immediately to mind. Most other critics make their statements based on ignorance, lack of comprehension, and lack of study.

Actually, I'm being super generous. Most people talking smack about Crowley base their opinions on what they heard about him rather than what they know about his life, times, and work. Because they're lazy and would rather feel good about themselves for thinking poorly of an icon of magick than actually do anything necessary to begin to become one themselves.

Folks, the Great Work is not a competition. You are not a better magician because you can point out what other magicians have done wrong. You are a good magician when you accomplish the Great Work, whatever that means to you.

Crowley can be useful in that pursuit for some people some of the time in accomplishing some things. There can be value in understanding what Crowley got wrong, but if that's all you see when you look at his Work, you're missing out on everything he got right...

And I'd suggest your time would be better spent pursuing something else.

Thursday, June 04, 2015

Pharos Mercury Talismans!

As mentioned, the Pharos Mercury talismans are available! It's your chance to get something that will counter those nasty Mercury Retrograde effects that plague us three times a year.

Getting the pics of these talismans was difficult, I suspect in part due to their mercurial nature, and the Rx didn't help. They are beautiful in real life.

Pharos is also going to be creating the silken cloth wrap suggested by the Key of Solomon for each person that buys one, but the silk won't be ready to ship until after July 1. You'll get the talismans first, though, along with a "Working with the Key of Solomon Talismans" guide I'm writing, an expanded version of the methods of operation I posted with the Venus talismans.

We have six talismans available. All were made on good elections, and finding a good election for the planetary hour and planetary day that line up with the instructions from the Key of Solomon isn't easy. We won't be able to make things with additional astrological graces like this until next year, for the Mercury talismans.

Four of them are on 2" silver disks, and were created when Mercury was direct, and dignified by sign and term (Pharos says they score a +7 for the election, if I understand right).

Two of them are on disks measuring 1 7/8" across, and were made when Mercury was direct, and dignified by sign and face (Pharos says they score a +6 for this election, again, assuming I understand right).

Please don't ask me what that means. Pharos is the brains when it comes to the astrological values. All I know for sure is that these talismans have the regular value of being made in the appropriate hour of the appropriate day by the Key of Solomon, plus the added virtue of being made at beneficial election times. What this means is that they will be more effective in your use of them for Mercurial manifestations.

We have the following available (note, if you get a "sold out" page when you try to buy them, someone beat you to it):

The "Miracle Maker"

This is the Second Pentacle of Mercury, which will "serve to bring to effect and to grant things which are contrary unto the order of Nature; and which are not contained under any other head." We have one on a 1 7/8" disc with a +6 election that costs $325. We have another on a 2" disc with a +7 election that costs $375.

I really wanted to keep one of these for myself, but I can make them myself, and the main reason I sell these things is so that people who aren't comfortable making them themselves can benefit from the results, so ... sigh. The things I do for you people.

The "Key to the Universe"

This is the Fourth Pentacle of Mercury, which is "proper to acquire the understanding and knowledge of all things created, and to seek out and penetrate into hidden things; and to command those spirits which are called Allatori to perform embassies." We have only one, on a 2" silver disc with a +7 election.

This talisman is extremely potent without the election, and is something every magician should have in their repertoire in my humble opinion. I mean, come on, you get to know ALL THINGS CREATED. Why we don't sell more of these at the regular price is beyond me. The spirits of this pentacle are adept at revealing information sources, providing insights, and making the kinds of connections that lead to the AHA! moments that make this magic stuff so fun and useful. This talisman is priced at $525.

The "Opener of Ways"

This is the Fifth Pentacle of Mercury, which "serveth to open doors in whatever way they may be closed, and nothing it may encounter can resist it." This talisman seems to be used by a lot of my clients to "open" relationship opportunities with people who are, for whatever reason, unwilling to start a new relationship with the client. It's also incredibly useful with cases in probate, for some reason. Any situation that's stuck falls before its influence, in my experience.

We have three of these available, one on a 1 7/8" silver disc with a +6 election that costs $325. We have another two on a 2" disc with a +7 election that costs $375.

Recap and Purchasing

Each talisman includes the silk cloth recommended by the Key of Solomon, which will be available after July 1, and the "Working with the Key of Solomon Pentacles" guide I'm writing. Talismans will be shipped separately from the silk cloths due to the delay in getting them produced.

Please select the talisman of your choice from the drop-down below, and again, if you try to buy it and it's already sold, you'll be taken to a "sold out" page, and you'll have to re-evaluate your selections.



Select the Pentacle from the following list:

Thursday, May 28, 2015

Seven Spheres and Black Work Course Reminder

A reminder, if you're interested in joining the upcoming Seven Spheres live courses, purchase them here by Friday:


If you're interested in signing up for the Black Work course, use this button to buy the course AND the live lessons:


And if you're already a member, check your email for the "Black Work Live Only" purchase link to get signed up for the live lessons.

I'll be doing the courses live using gotomeeting, and will be sending out an email to people who have purchased the courses with a link to join the broadcast on Saturday morning.

All classes will be recorded and transfered to a private Youtube channel. I'll send out the links to the recorded sessions as the courses are converted in case you miss them.

Wednesday, May 27, 2015

Tips for Getting a Tech Job

Alright, so the last post generated some good conversations about the things Millenials are facing that we crusty old Gen-Xers couldn't possibly understand. It turns out, life is hard. And you don't get to do what you want.

It's ... It's just so hard, you know?

And also, there are like 10 times as many people competing for the shitty entry-level jobs than I had to deal with, and it's a different world. So I'll put away my snark and talk turkey and maybe help some people instead of making fun of them.

Nota Bene: The following tips are entirely about finding work in the technical industry of the United States. It should be noted this is a US-centric post. I live here, I work here, I've worked here all my life. These tips might be able to be adapted to other cultures, but they might not work that way at all in the many, many places I've never been.

I should probably also mention I'm a good-looking able-bodied white male in my 40s overflowing with self-confidence and charisma. I have a midwestern accent that makes people trust me subconsciously, and I've played this game for years. I know the keywords to say in the interview to look like I'm what they need for the job, and I play on that without remorse.

In other words, I have some native characteristics that, frankly, make the things I'm going to talk about a lot easier for me than if I were a woman, or if I had an appreciable amount of melanin in my system. This shit I'm about to lay on you will not work for everyone, and it's not fair, and I get that. I'm not saying you have to be a white American man to get a benefit from these tips, but you should totally take that into account when looking for ways to apply this stuff to your situation.

On with the tippage!

First things first: Know What the Tech Industry Does

The technical industry in the United States is based on hardware and software solution development. The key word is "solution." Solutions are not necessary when things are cool and working well. Solutions are about solving problems.

All projects that pay techies money are designed to solve a problem. You must understand this fundamentally before you even consider applying for a tech job. There will be problems, and you will be working with a team to come up with a solution. If you don't want a job with problems, the tech industry is not for you. Some might say "jobs" are also not for you, but not someone who has put their snark away, that's for sure.

All solutions, whether hardware or software based, have two basic phases. In the first phase, the solution is developed. In the second phase, the developed solution is released to the people whose problems are being solved. Solutions are the "products" created by techies.

When the solution is being developed, it is generally referred to as being "in development." When it is released to the users, it is generally referred to as being "in production." This is because the second word in Technical Industry is still Industry, and the industrial revolution has shaped how we think about what work is all about. Most of the shit we do is shaped by 19th century thinking. Never forget that, because otherwise you'll never understand why you have to go to a building to do a job you literally use laptops for that you can do from home over the internet in the 21st century.

The Development Lifecycle

The development of a successful solution follows a process. This process is called the "development lifecycle." All development lifecycles will consist of gathering requirements, developing a product that meets those requirements, testing the product, deploying the product, and training the users.

People have been documenting different ways to approach the development lifecycle for years and years. Wikipedia is an excellent resource to learn the differences between approaches. You want to look up things like RUP, Waterfall, and Agile. Agile development is really popular right now, because it sounds like it's flexible and efficient and it promises to pump out solutions quickly, without spending a lot of time on things like ... documentation.

If you know anything about Total Quality Management from the 1980s, try really hard not to mention to anyone telling you about the latest form of development being implemented at your company, "Oh, it's TQM in different words! Why not just call it TQM?" They will give you the hairy eyeball, and pass you over for promotions.

Keeping silent is a big part of being a Techie.

Besides, it doesn't matter what form of development your company is using. No one follows the prescribed processes literally anyway. It's really more of a set of guiding principles. The only time you'll need to know anything about these phases is when you're being interviewed, because HR and Management tend to think everyone is actually using the techniques they spent so much money implementing to improve the design process.

Wikipedia will tell you all the right buzzwords, but remember, it's just gathering requirements, developing the product that meets the requirements, testing it to prove it works, deployment, and training users. Common sense, when you think about it.

Requirements

Identifying the requirements is the most important part of the process. Requirements give you a list of things the product has to be able to do. They tell the developers what to develop. They give you a list of things to test when you're done developing. They give you a list of things to document, and an outline for your training presentation. They guide the entire development process, and ensure the users end up with what they actually need to solve their problems, instead of yet another thing that doesn't work.

Requirements development also takes place in phases. You may begin to see a trend here. Pay no attention to the phase trend, the trend seeing phase is just a phase. You'll soon get tired of seeing trends, and move on to the next phase, apathy. But let's get back to the first phase of requirements generation.

The first set of requirements is created by the Project Manager and the Business Lead. The Business Lead is a middle-level manager ("Vice President") who is either directly or indirectly faced with the business problem that requires the technical solution. The Project Manager is in charge of interviewing the Business Lead, identifying the things that the product should do, and creating a list of these requirements. This list is called the "Business Requirements," and it is reviewed and approved by the Business Lead. In well-run organizations, the Business Requirements are numbered to enable you to track each aspect of development, testing, and deployment to one of the Business Requirements.

The Project Manager then takes the list of Business Requirements to the Technical Lead. Together they take the input from the Business Lead and identify ways a technical solution can meet the business requirements. They translate the stupid vaporous general requests from the Business Lead into technical language that a developer can understand. This becomes the "Detailed Requirements" or "Technical Specifications." Any similarities between the Business Requirements and the Technical Requirements beyond the numbers is purely coincidental, and probably indicates the ink on the Project Manager's PMI Certification is still warm from the laser printer.

The Technical Lead then takes this list to the Developers, and may send a copy to the Quality Assurance (QA) team that will be responsible for testing the product before deploying the product.

Project Managers usually spend a great deal of time developing Change Control Procedures to ensure that any changes to the requirements are documented, discussed, and distributed to all team members regularly. Meetings are held weekly for approximately one week, at which point all changes to requirements are documented in emails between the Business Lead and Project Managers. Sometimes they let the developers and testers know about these changes, but usually not until after the previous version of requirements has been met.

Product Development

Developing the product or code that meets the requirements is the next step. Products are considered "in development" when the requirements have been turned over to the developers, and they begin to create the product that meets the Technical requirements in an attempt to solve the problem the Project Managers understood the Business Leads to have, which may or may not be related to the actual end-users' experience, interest, or job description.

IT Products are developed in a "Development Environment." This refers to a simulated mockery of the systems, resources, data, and equipment that the end user will be expected to have at their fingertips while using the product. Note: The end user will access the product in a "Production Environment." The Development Environment will resemble the Production Environment in exactly the same way as the Technical Requirements resemble the Business Requirements. Any similarities are highly discouraged and will be noted as a waste of resources during the Budget Planning phase in the third quarter of the fiscal year.

The bulk of "development" is usually done the morning of the release, to the angst and chagrin of the testers, trainers, and ultimately the end users, though they usually don't know why the products aren't doing what they are supposed to do. This is known as a "production issue."

Developers: Some Notes

To understand the development process, some attention should be paid to the actual developers. They are a rare breed. They are highly trained in using Google to look up code snippets that sort of do what they think the Technical Requirements are talking about, and are therefore very expensive. Due to their high price tag, no project actually hires enough developers to code their project, which tends to put them under a great deal of pressure to develop working code in impossible time frames, leaving them cranky and bitter.

Because they are often under a lot of pressure and time constraints, Developers can't be bothered to use whole words, unless it confuses their audience. For example, they will refer to the Development and Production environments as "Dev" and "Prod." They will use inappropriate acronyms to refer to every part of their project, often in ways that make obscure references to science fiction plots written by Joss Whedon and Stephen Moffet that no one gets but themselves.

The stereotype of the code monkey who runs on various forms of caffienated products and Cheetos is demeaning and rude. Do not bring them Mountain Dew and Cheetos and expect them to be pleased, or to get your project bumped up in priority. They are bitter, angry and far too strung out on caffeine and undernourished as a result of their Cheeto, Ramen, and Pocky based diet to even think it's funny. But leave the Mountain Dew and Cheetos anyway.

Testing

While the Dev team is working on the code, the Quality Assurance (QA) team is putting together the Testing materials. These consist of a Test Plan, Test Cases, and Use Cases. The Test Plan discusses how testing will be done, and identifies the process of pointing out the Developers have totally missed the point of the Requirements. This document is then sent to all members of the Project. Next they develop Test Cases, Use Cases, and occasionally the Test Scripts. These artifacts are designed to list all the steps that are necessary to see if the Requirements are being met.

When the Developers are finished creating the code to (ha ha) spec, they load it into a Test Environment that is somewhere between the Dev and Prod Environments. Theoretically, the Test Environment is an exact duplicate of the Prod environment, but that costs a lot of money and, in Health Care and Banking industries, breaks several laws and exposes the corporate executives to "Risk."

Risk is bad, and several organizations have "Risk Managers" who create mitigation controls and policies that usually turn into mandatory training videos that have to be taken on a quarterly basis. To all tech workers lower than middle management, these are known collectively as "A Huge Fucking Waste of Time."

When the code is loaded to the Test Environment, the QA department pretends they are the Users, and checks to see if the product does what they think the product is supposed to do based on the conflicting documentation they received from the Technical Lead and the Business Lead. When it doesn't work, they write up "Bug" descriptions and submit them to the Dev team. If the Dev team is not ingenuous enough to find a way to blame the QA team for testing the product wrong, they are forced to "fix" the code and redeploy it to the Test environment.

This process repeats until the code does what the QA test says it's supposed to do, or until the Technical Lead changes the Requirements to match the code.

QA teams are notorious for complaining about how the Business Requirements don't match the Technical Requirements, and that the Dev and Test environments don't match Production, and that deploying the code will probably break all the dependent processes on the network.

Nobody likes the QA department.

Training

When QA has determined the product has passed all the requirements, or have quit in disgust and gone on to other companies that promise this time it will be different, it's time to unveil the finished product to the Users, and teach them how the product will solve their business problem. This is usually done at a "Brown Bag Session," at which you are expected to bring your lunch to the conference room and eat quietly while you're being trained so you don't lose production time.

Training is based on the requirements documentation, and includes step-by-step instructions in how to use the product to perform each task represented by each requirement. Screenshots of the software are often included, but are usually based on early Dev works in process, and bear more resemblance to PowerPoint mockups than anything the user will ultimately see.

By the time the product has made it through development and testing, it seldom resembles anything even remotely related to anything the target audience actually does on a daily basis. Users are surprisingly not interested in learning new ways to do things that do not actually solve any problems, and so have few questions when the last slide is presented.

That is ok, as you will see when we get to the Production Phase.

Deployment

After the product has been developed and tested, and the users have been trained, the product itself is released into Production. This process is a cleverly orchestrated routine led by the few technical people in the organization that understand how computers really work.

This is the only process that regularly goes well, and chances are it's because the system administrators (don't worry, if you're not one it doesn't matter if you know what they do; think of them as wizards who make everything better because they can tell management "no, computers don't do that" and are not fired) have set up a sequestered part of the network where the stitched-together shambling corpse of a product can be dumped without it infecting anything else.

The Production Phase

After products have been deployed, they are considered to be "in production." This does not mean they are being used, it simply means they are not being developed or tested at the moment.

The first few weeks after deployment are exciting times. The Project Manager, Business, and Technical Leads have all been assigned new projects, and the product maintenance has been dumped on someone's lap while they were on vacation. As a result, no one really knows who to contact if something goes wrong.

The Development team can't wait to hear how great their product is at solving the business problem. The remnants of the QA team can't wait to see the product fail miserably. The Users are all hoping no one really expected them to be paying attention at training.

Eventually, however, someone tries to use the product. This begins the Product Maintenance cycle. Typically, a User tries to Use the Product, and it Doesn't Work. They then contact the Help Desk, who have never even heard of that Product before. They begin the task of tracking down the Product, its developers, and the primary support contact, who has since gotten back from vacation.

The Support Contact is usually not in a very good mood. They have usually spent less time familiarizing themselves with the new product than they have spent trying to get the product to be someone else's responsibility, but everyone else has hidden their vacation schedules from the shared calendar. As a result, when a User finally gets through to them, they are surly, confused, and not very happy. The User attempts to explain what the product is, what it's supposed to do, and what aspect of that is not working.

The Support Contact then tracks down the Business and Technical Leads, who direct him hastily to the development team member who worked on the project before getting back to their current priority project. Eventually the User gets to speak with the Developer, who finally gets to see what the problem really is, and how to fix it. They then contact one of their friends in QA, explain what it's supposed to actually do, and let them know they need it tested. The QA person contacts the User and asks them to make sure the product does what it's supposed to. Everyone signs off on it, and the updated version is released to production.

This may repeat as additional features are accessed by the User.

Ok, so ... you said Tips and ... something something Tech Jobs?

Well noted, awesome reader, you remembered! Also, well done reading this much in one sitting. Please comment "gloat" on FaceBook's comments to claim your gloat prize, which is the warm feeling you get from being in on the joke.

Vocabulary Matters

I didn't think the overview of the Tech Industry in America would take so damned long, but really understanding this thing is key to getting these jobs. You need to get the vocabulary that will get you hired, and to get the vocab, you need to understand the process of tech projects. Google software development lifecycle (SDLC) and read all the Wikipedia results you find, click links to specific types. Study Agile, RUP, Waterfall. Know them well, and learn the keywords.

Pepper your resume with keywords from each phase of development. Design, architect, develop, requirements, testing, QA/QC, monitoring and control, etc. Sound like you know what you're talking about, tell the story in your resume about how you know this shit like the back of your hand. This is going to get you into the interview.

Show at least two years of relevant experience in each phase of development on your resume. If you can't make your actual experience sound like SDLC phases, study SDLC more and get creative interpreting your old jobs or college projects. You've done all that shit at some point, you just didn't realize you were doing it. Just make sure your references will back you up on anything you claim you did.

As you can see, the Tech Industry is a mess. As a result, there is a high turnover rate. This results in a lot of pretty good-paying jobs almost always being open somewhere, often somewhere nearby. Most companies go through temp staffing agencies. Most tech temp staffing agencies use Dice.com to find potential matches. Most jobs are not posted to Dice. Don't bother applying to posted jobs, spend your time reviewing job requirements for common keywords, and making sure those are in your resume. Update your resume and your profile on Dice, and let the recruiters contact you. Update your resume on Dice daily, so it always shows up in the "just updated" list. All you have to do is make one change to the resume and save it an upload it to get to the top of the line.

Don't work with any contracting company whose representative's accent is so bad you can't understand it. Only go with contracting companies who represent direct clients. The fewer parasites between you and the people you're working with, the more money you get to keep.

Always ask for $100 an hour when they ask what you're looking to make. They'll laugh. Don't laugh with them. Wait a sec, then ask what they were looking to pay. They get serious then. Whatever they say, you say you were looking to make $10 more an hour. They'll come back with something more serious, and you can take that, as long as they pay overtime. If they don't pay overtime, get no less than $5 more an hour than what they offered, and say the magic word "firm." They'll say, "I'll submit you at that, but it's a little high, will you be open to negotiating if they come back with something lower?" You'll say, no, that's my rate, and they'll come back with something less anyway. They always do. At that point, tell them you'll interview and discuss rates after if you like the job.

Study the job req, and grill the representative. Ask what they know about the job, get as many details as you can so you can build your story for the interview. If your resume doesn't have the keywords of the job description, add them, and then update your resume online and with the recruiter.

Interviewing

Go in a suit. Look better than they do. If they say something implying you're overdressed, smile big and say, "of course I overdressed, I want to get an offer here!" No commitment, and they'll laugh, and see you're ambitious.

Look at them. Keep a blank expression when they are speaking, but make eye contact, or watch their lips while they speak. Show attentiveness, but let them project their desires onto you. Reflect their desires. Don't laugh unless they do first.

Let them ask a couple questions, nod a bit, answer them using the keywords from your research and their job requirements at a really high level, then say something like, "But what is it you're looking for now? What's the project?" Then let them tell you everything they want to hear.

Smile when they say something you recognize, wrinkle your forehead when they say something is stressful, or if they aren't being clear in their description of the project.

Interview them. You need to know what SDLC they use, where they're at in the project lifecycle, how many resources are assigned, and what they expect you to do. You need to know who the users or audience are going to be. You need to know deadlines, constraints, and if there are any potential roadblocks.

Nod and go, "mhmm" when they answer.

If you really understand what I wrote about above, you'll be able to turn the interview around. If they are concerned about your experience, tell them what you haven't done you'll Google. Tech jobs almost always consist of being really good at using Google to find other people who solved similar solutions and posted it publicly so everyone can see how cool they are. Your interviewers are doing this too, they'll want to know you know how to do that.

If they ask about a certification, tell them you're thinking about getting one. Know which MSDN certification applies to your job before you go, and be ready to say you were looking at it, but aren't sure the value of the cert is worth the money it costs when you've been doing this for so long anyway.

Specialize Generally

Be really good at a lot of things. Know the whole cycle, intimately. Every time someone at your new job asks you to do something new, smile and say yes early in your career. Do the shit work cheerfully. Learn something about process flows, spreadsheets, word documents, database management, and SQL queries. Learn how to code a web site in HTML, be able to put text and graphics together in meaningful ways as soon as possible.

Experiment with every program you're given to use. Explore tool bars and hidden menus. Lookup keyboard shortcuts. You never know when being able to right-click will make you look awesome.

Being familiar with everything is great, but eventually you'll want to start to specialize. Pick a niche and go with it. Microsoft products are used everywhere, and if you know how to code in VBA, you can do amazing things with it, for example. Get certified when you can afford it.

Aim Realistically

Starting from scratch, you won't make 6 figures. Figure you'll make $35-50k a year your first three years, tops. After 5, you should be making 50-65k regularly. After 10, over 6 figures. If you're not, you didn't specialize enough. Data architecture is easy, and ubiquitous, and it pays well. Specialize in that if you haven't picked something by now.

Be Positive for Positive Results

Smile a lot. Don't complain or engage in the snark I did above, except at lunch when no one can hear you. Don't bitch, don't backstab, don't complain. Show up on time to work, leave your personal problems at the door, and don't be dramatic. Be agreeable. Do your best. Be calm under pressure.

Tuesday, May 26, 2015

Everything I Know about Jobs is Apparently Wrong?

I saw the video below this morning, and I realized that people must be growing up and moving out into a totally different world than I did in my twenties.


I hitch-hiked across the country in 1994 or 1995, and basically I stayed in shelters, or slept in a one-person tent I'd pitch alongside the highway. When I needed money, I'd ask the shelter management where the day-labor place was and show up there at 4:00 AM, work 10 hours, and get a check for $35 (after taxes and check cashing fees) that night. I did that a couple weeks with a friend, and we made enough money to get a room at a weekly apartment place, where I was able to shower regularly.

We ate ramen, and got nicer clothes at Goodwill. I went to ManPower and they tested my skills with Microsoft Office, and certified me as a "Master" because I knew how to use the right-click button to open a menu and find the things I needed to insert pictures and fonts and things. With that I qualified for better paying positions. I showed up daily, I did my work, and I smiled a lot. I used that technique to get hired full time, and eventually to become a Tech Writer, where I learned a lot of stuff about SharePoint, and now I get over 6 figures a year to do some pretty advanced stuff that I picked up along the way.

But apparently, this path is somehow gone. Millenials can't find work? I don't get it. At my current job, we hire people through temporary staffing agencies, and if they do good work and have a pleasant personality, we hire them full time. That's how it's been my whole career. How is this not working anymore?

Don't people expect to have shitty jobs until they're in their thirties? Don't people get apartments with their friends until they can afford something better? Isn't that ... normal? What the hell happened?

I secretly suspect people just don't want to go through the processes that are in place in our society to get a good paying job. I know I'm basically saying, "kids today..." but seriously, is it that hard? Am I missing something here? It's hard, it's annoying, it's boring, and it doesn't pay well. You have to put up with bullshit and smile the whole time, even when you don't want to. Is that what people are complaining about?

Someone help me out, things aren't making sense here.

If this is the attitude people are bringing to the table, they aren't going to be very happy with how magic works either.