Tag: RufusAstraCheck

Tag: RufusAstraCheck

  • You at your Worst: Not that Bad

    So this morning I found myself going over the RO Behavioral Balance Sheet for 2015, making lists of the best and worst things I did last year to see how I’ve been doing on the overall “expression of my Word” thing in this Great Work business.

    It was mostly good. I’m way behind on a lot of things I said I’d do, but the wrap-up is in sight. I’m happy, successful, and people are happy with me in general (unless they’re waiting for a Seven Spheres Conjure Kit, some of those people are pissed, but they should be ready by end of January, I promise).

    But one thing stood out in my mind in the “fucked it up” column. One memory. The worst thing I did last year. The thing that as I’m falling asleep five years from now my brain will pull out and be all, remember when you did THIS? HA HA, YOU SUCK.

    The worst thing I did last year was this:

    Someone posted a pic of what looked like an altar designed to conjure, with absolutely no exaggeration, the Primordial Archetype of the True Hipster God (you probably haven’t heard of him).

    The table it was on was like one of those spools that construction teams use to wrap fiber optic or copper cable that you see on construction sites. Like a huge wooden spool made out of terribly cheap plywood, obviously found on the side of the road. I can’t remember all the details of what was on it, but I remember a large can of Pabst Blue Ribbon beer, some cheap looking tea lite candle or other kind of candle, some really vintage looking stuff that had a shabby “found-item” look to it all, and it was like really scarcely decorated.

    I took a screen shot of it and posted it to Facebook with a hilarious tag about conjuring the Hipster God, of course. It was brilliant, and witty, and funny, and barely mocked anyone who isn’t already self-deprecating.

    After getting a lot of likes, because likes are important, and my friends posting some really funny stuff about what the Hipster God was all about, I get a PM from the dude who posted the pic. It turns out they were honoring a friend who had committed suicide. The stuff on the altar as stuff the guy had liked in life. Things that defined who he was.

    And I turned it into a joke. Centered entirely around the kind of guy he was.

    Before he killed himself.

    For fuck’s sake.

    I felt like TOTAL SHIT. Deleted the post, apologized profusely, and basically tried to make things not shitty for that guy and his friends. I was an ASS.

    I’ll do some Work on healing that memory and get on with my life over time. This isn’t the worst thing I’ve ever done, but it’s pretty shitty. I’ll move on and do other terrible things this year, and one of them will stick out, and it will haunt me, and like most people on the planet, my first urge is to keep it to myself.

    So why make it public now?

    I don’t entirely understand how it all works, but for some reason people listen to me when I talk. More people will read this post than belong to the OTO and A.:A.: combined in the entire world.

    And a lot of you are like me. Otherwise you wouldn’t be reading this.

    You fuck up a lot, but you don’t mention it, you keep it to yourself. You punish yourself for being a total asshat that one time, and that other time. You think the things you do were awful, and there’s a part of your brain that will punish you all year for some shit you did.

    And no one else is talking about how shitty they are as a person. We post the good stuff most of the time, and we roll our eyes at the people posting their shitty stuff. We keep our own shit to ourselves.

    Everyone is doing that all the time.

    So there’s no honest, true standard of behavior we can use to figure out how we’re doing, compared to other people. So you flipped off that asshat in traffic and later felt bad because you were PMSing or hungry or horny or something. You made fun of the fat people at the gym, who are actually there to do something about getting healthy. You did that one thing that no one else knows about, and it haunts you and you feel stupid, dumb, ugly, insensitive, awkward, whatever.

    And I got to thinking this morning that always posting how awesome things are is bullshit. Sure, I completed the Great Work, created the Philosopher’s Stone, spoke my Word of the Magus and everything.

    But I also made fun of a memorial to a suicide victim.

    I wanted you all to know that other people, people you listen to and respect, are fuck-ups who did terrible things they feel guilty about. I want you to feel better about that one thing you did that you think is so awful. I want you to know that the worst thing you did last year probably wasn’t as bad as you think it was, really, and you should cut yourself some slack.

    Unless it was worse than what I did, you sick fuck.

    If it was, don’t do that again, for sure, eh?

    But don’t beat yourself up. You’ll do far, far worse things before you die, probably. Let that one terrible thing go, and look in the other column, the awesome things you did last year. I got a bunch of people to do magic to make their lives better financially and emotionally and intellectually. I inspired some crusty curmudgeons to see their religion as alive and hopeful and active instead of as a backdrop to their personal dramas with their lodge mates.

    You did awesome shit too.

    You’re awesome.

    Move along.

  • The Most Wonderful Time of the Year…

    Happy Holidays, all!

    I spent Thanksgiving with none other than Frater Barrabbas and his lovely wife, and the shared members of our local OTO lodge. In a word:

    AMAZING.

    Great food, amazing cocktails and wine, the FEAST of the Ishim! It was fucking awesome. We celebrated the hell out of the harvest.

    Guys, do magic. It makes your life so much better.

  • Update on Kits!

    Hey all, I know I said I’d start sending these out in September, but I ended up working 80-hour weeks at my day job, and only just got all the materials in.

    They should start going out in the next two weeks. They will go out to the people who have been waiting the longest first.

  • 7 Spheres Conjuration Kit

    So, at least one person keeps asking me how much I’d charge to put together a complete set of tools for the Seven Spheres book, so I figured I’d throw together a whole kit.

    It will be $175 for the tools alone, or $225 for the book plus the complete kit.

    The complete kit will include:

    • 1 Ebony Wand, 3/4″ X 12″ to Trithemian specs
    • 1 Table of Practice, with the Kings of the quarters (Paimon, Amaymon, Egyn, Oriens)
    • 1 quartz crystal scrying point, consecrated. This will be 2-4″ high, 2-3″ wide. I don’t control the growth of crystals, so there’s no conformity. If I went with quartz crystal balls, I wouldn’t buy this kit, it would cost too much. I like using my quartz point anyway.
    • 7 1″ circular silver talismans for the seven archangels, the same ones I use. They’re all in sterling silver, which receives the rays of all the planets nicely. I’d do the 7 traditional metals, but I’m not working in lead or tin these days. I’ve gotten enough lead poisoning, and silver works great.
    • 1 brass incense holder
    • 1 pack of stick incense, nag champa, my current favorite for all spirits. 

    Shipping is not included, it will likely be around $5-15 in the US, $25-50 overseas. I haven’t checked.

    I’m only making 7 sets of these things, and they will not likely be shipped until early September. Please order using the button below. As long as you can place an order, they are not sold out.

  • After the Stone… Projection

    I’m entering a new phase of my Work, these days, and I’m pretty excited about it. I want to pursue some things Sef and Chris Bradford and a few other Gents had discussed back in the day under a whole new skin.

    When I started “Head for the Red,” it was entirely about my pursuit of the accomplishment of the Great Work. I researched the practices of magicians throughout the aeons, found a really convenient way to contact the spirits, conjured them, and performed the Work. I “created the philosophers stone” about three years ago, and have been working on figuring out the best ways to grind it and project it into the world as the universal panacea.

    In addition, as many of you know, I joined the A∴A∴ and the OTO a couple of years ago, and it’s shifted the focus of a lot of my Work. I’m still
    conjuring from the grimoires regularly, and maintaining my relationships with the spirits, but I’ve also found a framework for the things revealed to me in the 8th Sphere.

    I realized a lot of things when I hit the 8th, and I want to pursue those things more hard core in my public life than I have been here lately. There’s an aspect of the Work that applies to every man, woman, and child upon the face of the Earth that doesn’t have any press right now, and it needs it. Badly.

    The Seven Spheres are just the beginning. There’s more, baby, so much more.

    And the A∴A∴ and OTO stuff is also pretty cool, but I haven’t felt nearly as comfortable about posting my experiences in the Thelemic systems here because so many of my readers are not in that particular current, and I don’t want to come off like I’m proselytizing Thelema or anything. We got together over a lot of bitterness based on my experiences with the Golden Dawn, and I respect that a sizable base of my readers aren’t interested in lodgy-type things.

    So going forward, I’m going to be splitting my interests between this and a couple other blogs. Over time, I’ll see where I end up, but right now I’m going to keep maintaining this site, posting about awesome magical things in the traditional Hermetic current, and things of that nature.

    I’m also going to be taking my 8th Sphere revelations to the Work of Kings blog. That’s where I’ll be getting into the Applied Hermetics stuff we had talked about years ago. It’s about fucking time.

    Aaaaaand, I’ve got a lot of stuff to talk about that is primarily of interest to folks in the OTO and the A∴A∴, which will take place on my Horns of Cerastes blog. I’ll ventilize, I’ll advertise, I’ll theorize, and I’ll proselytize.

    Oh yea, I’m also getting a new web site. Because it’s just that time again.

    Fasten your seat belts, it’s going to be a wild ride.

  • 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.

  • 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:




  • 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.

  • 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.