In terms of programming, there is the “front end” of an application and a “back end.” The back end being what goes on “under the sheets” as Tom, my instructor, is fond of saying. It’s the things you can’t see–the methods and functions that make everything work. And the front end is what you see: the fonts and colors in the text, the placement of images and titles, the layout of the websites. Thus far, we’ve only focused on the back end. Today, we started with the front.

CSS stands for cascading style sheets. It’s what makes your websites look like a website instead of a boring list of words. In my lead up to Tech Elevator, I studied HTML, JavaScript, and CSS. So I was somewhat familiar with the syntax and layouts. But I spent most of that time with JavaScript because it’s way more fun than CSS and HTML. So now it’s time to learn in earnest.

Tom went over the general things to know pretty quickly and then we were given our exercise. It was different than the homework we usually get. Instead of a list of problems to work through, we were given two HTML documents, one styled with CSS and one not. We were told to make the one look like the other.

At first it seemed impossible. Everything we typed either had no effect on the file or the effect was so chaotic and radical that we had to immediately set it back. It was pretty frustrating for about an hour.

But then, oh so slowly, we were able to find the right spells, sculpt it in the right way, that the two documents started to grow some similarities. The lecture ended at 11:30 and by 3:00 I had a pretty good facsimile.

CSS takes some practice, but I could see how it could be fun after a couple dozen hours of experience.

My sleep has been all messed up.

I’ve been an early riser for several years now. I get up two or three hours before work so that I can exercise and write. I like to get home after an eight-hour day and have all of my goals accomplished so that I can relax. I’ve been doing much of the same during my tenure at Tech Elevator. I get up around 5:30, exercise, and then get to the North Side by 7:30 to either finish up work from the day before, run some drills on techniques, or just hang out and talk with the other students.

But when I was working at Barnes & Noble, I was able to sleep peacefully. Not the case with my current situation.

Getting up at 5:30 means that I start to feel pretty drowsy around 8:30 or 9:00 pm. I’m in bed by 9:30 and almost always asleep by 10:00. Then the weirdness starts.

Have you ever been quasi-asleep and thought that you were in public? Like, at a school dance, or maybe at a party? You walk around having strange conversations with the party-goers with the half-realization that you are, in fact, in your bed. Now and then you wake fully and say, “What am I doing? I’m not at a party. Go to sleep, dummy.”

I have these half-dreams every single night. And they’re about coding. I can see the code in front of me in the darkness of my bedroom, the blue “if” statements, the green Classes, the amber string text. The red, squiggly lines of my mistakes haunt me. I turn the code over in my head with otherworldly dream logic trying to find the right loop, the correct constructors to solve my problem. Every hour on the hour, I wake up and say, “You’re not coding. Go to sleep, dummy.”

I can’t stop. I rarely sleep deeply anymore. And when I do, the dreams have been vivid and intense. Not every single dream has involved Tech Elevator, but most of them have. In one of my strangest dreams, I took my parents to the school to show them where I’ve been studying. Also, apparently, I had left my wallet there by accident. I went into the .Net classroom to retrieve the wallet and when I came out into the main space, I found that my mother had torn up several of the floorboards.

I was aghast at the turn of events. When I asked why she did this, she said she thought she was helping. She also admitted to tearing up floorboards in the hallway leading to TE and in Caitie’s office (which I believe in reality is carpeted).

I suppose I could parse this with some Freudian queries, but I’m just going to let it go. I need less thinking in my life, not more. What I need more of is sleep.

The capstone work was punctuated today with a field trip to the corporate headquarters of Dick’s Sporting Goods. Tech Elevator is on the Northside of Pittsburgh, in the city proper, and Dicks headquarters is on the fringes of what might be called “The Greater Pittsburgh Area”, out past the airport, nearly twenty-five minutes away(without traffic). The commute would be challenging if I end up working at Dicks, but that would be the only check mark in the “cons” column.

Dicks, Golf Galaxy, and Field and Stream are all under the same corporate umbrella and the complex on which their employees work looks more like a massive college campus than an office building. I walked towards the giant structure with Jack and Drew and Drew identified the style of the building as brutalist architecture. He’s right. It’s massive and blocky and sort of intimidating. Way different than the sleek towers and bridges of downtown Pittsburgh.

The lobby was reminiscent of a pricey hotel, except themed with sports–comfortable leather chairs, Dick’s logos, and murals of swimmers in blue water, muscular runners loping over a hurdle.

The monks of Tech Elevator were greeted by Brooks, a Dicks manager in charge of talent acquisition, among other things. Brooks ushered us to an auditorium where we were treated to a tech talk by their CTO.

Afterwards, we stood up and performed our Elevator Pitches. It was only thirty seconds of speaking in front of a crowd, but most of the TE students were battling some nerves. The process felt somewhat manufactured as we announced who we were and what intentions we had, but Brooks and the other Dicks employees seemed invested in our stories and often made comments or asked questions.

Then we took the tour. I got my first look at a real floor full of working programmers. Dicks is in the middle of a transformation. They are redoing all of their floors from cubicle farms to an open work space. And it’s easy to see why, the cubicles looked like the topiary maze in the Shining, except with beige walls and somehow more sinister.

But the open floor plan was nice. Programmers worked in pairs, sitting or standing in front of large black monitors, colorful code on the screen like glow-in-the-dark graffiti. It looked like fun. It reminded me of Tech Elevator, actually.

After that we were shown the amenities. They were plentiful and impressive. There are several restaurants in the complex, burgers at one stand, pizza at another, really good-looking health food at a third. There’s even a fully functioning steak house where they entertain partners and clients.

Outside in the February cold, we saw some basketball and tennis courts. Tennis is my favorite sport to play, so this was enticing for me. Next we were taken up to the gym area where there is an indoor track, a pristine wood-paneled basketball court and a full gym with enough weights and cardio machines to handle a good influx of exercising employees.

This would be a fantastic place to work.

At the end of the day, I would say my main emotion was impatience. I’m ready to get working. Either at Dick’s Sporting Goods or somewhere else. I’m ready to be there. But…not yet. There’s much more to learn.

Today I spent more than ten solid hours concentrating on the second capstone with Jack.

We’re both early birds, so we tend to arrive at Tech Elevator between 7 and 7:30, nearly two hours before class starts each day. When a capstone is on, there is no lecture. So Jack and I hit the ground running at 7:30, coffees steaming in front of us and the glow of the computer screen in our eyes.

We made a ton of progress before breaking for lunch. As I said yesterday, our second capstone is a reservation system for national parks. We have to create a menu that takes a user through viewing the names of parks, the subsequent campgrounds within, and then view the sites within those campgrounds that are available to book and, ultimately, the ability to book a new reservation.

By noon, we had everything finished except for the search of availability, the booking, and the integration testing. We were in such a flow state that I think we would have worked straight through lunch if that were an option. But it wasn’t. We had visitors.

BNY Mellon bought the monks of Tech Elevator lunch today. And it was excellent. A mound of marinated steak strips with peppers and onions, salad of green beans and chicken glazed with mustard and mayonnaise, and a quinoa salad with cubed sweet potatoes. A good spread.

BNY Mellon sent three representatives of their tech division, one of them a former Tech Elevator student, recently hired by the financial giant. They made their pitch to the students and all went well. I’m certainly interested in employment there and had a good conversation with Tom, a manager in charge of infrastructure.

Then it was back to the national parks. Jack and I almost finished. We nailed the method which allows us to book a reservation, but we got hung up on ciphering out the dates that have already been booked. These dates where someone already has a reservation should not show up when the user searches, but some of them still are. And we don’t know why.

But we’ll fix it tomorrow. We made good strides and really only have some buttoning up to do. And it’s not officially due until Tuesday! Hooray!

Today we were assigned our second capstone, the second major project of the cohort. Last time, we were tasked to make a Vending Machine. For this capstone, we are to make a registration system for the National Parks.

This might sound larger in scope, but the word on the street is that this is the easier of the two. For me, it will almost certainly be the easier of the two. We were again randomly assigned our partners and I drew Jack.

Jack is a 19 year old programmer who recently dropped out of college because it was going too slow for him. His knowledge is deep and effortless. Working with him today, it’s clear that he loves coding intensely and he’s psyched to have another capstone to work on.

This is the first time that my pair partner has been a much higher skill level than me and it’s a completely different experience. Whereas my goal in the past was to keep the project rolling forward and hope to finish on time, I found myself this afternoon making sure that I kept up, made myself useful, and understood all the code that was going into our registration system.

I was able to do this, I think. I wrote the methods that collected the campgrounds and their subsequent sites together and Jack tackled the much more complex business of the menu and its interface with the users. We worked well together. I tried to help out when he got stuck and was able to make a suggestion once or twice that helped him out. On the flip-side, every time I got stuck on syntax or a problem with scope, Jack was able to glance at my code for a few moments and point out my issue.

It was nice. Humbling, but nice.

We’re coming in early tomorrow to get a long day in before Friday, which will be shortened by a trip in the afternoon to Dick’s corporate headquarters. I’m looking forward to a day of coffee, coding, and teamwork.

Long day.

The last two lectures have concerned the method for accessing databases through our code using an intricate series of classes and functions. We were in pairs during the exercises, the same pairs as last week, so I was with Diane once more.

We fell a little behind yesterday, as I had a scheduled meeting with Caitie about the Pathway Program and Diane had a hard out at 4:00. We planned to catch up today.

The exercises assigned today were designed around building integrated tests (think unit tests, but for the code/database hybrids) for the code that we wrote in pairs the day before. Diane and I had a long day ahead of us as we had to catch up and then work on the new stuff.

Diane fell ill and left right after the lecture. I planned on finishing the exercises from yesterday and then getting as far as I could on the integrated tests. But, as often happens, things didn’t go as planned.

I got hung up several times on Monday’s exercises. Not wanting to dilly-dalley, I hit up Tom as much as I could with questions to keep moving forward. By the time I (sort of) finished the Monday exercises, it was nearly 4:00. I had spent three hours catching up. I worked until 5:30, but I was fried.

Everyone was having trouble with the integrated testing. It’s incredibly complicated (or, at least, it seems so right now) and when you try to follow the problem through the debugger, it doesn’t work like it does when you’re dealing with straight code. There are too many dependencies, too many places for mistakes to happen. It’s hard to narrow down.

The second Capstone begins tomorrow. The grains of the hourglass are decrementing rapidly on my time for integrated testing.

I was able to get double the reps in on the coding portion of the database and code integration, so that was good. And I did enough of the testing to feel somewhat comfortable with it, but I don’t see how Diane and I can catch up and turn in a finished product. We have hours upon hours of work that still need done. This looks like a moment where we take a subpar grade and move on. We’ll see how tomorrow goes.

After our lecture this morning, the third cohort of Tech Elevator gathered in the main room for a discussion about different types of employment and the means with which to acquire them. In other words, Caite, the Pathway Director, guided us through the worlds of consulting, contract work, and full-time employment.

These are the three major avenues for a programmer to go when seeking employment, and depending on your lifestyle, each has its benefits.

First, the contract work. A company will hire a programmer for six months, say, or a year. Sometimes it will be contract to hire, but often the employment ends with the contract (and sometimes the employment ends before). The coder can get a higher per hour salary for these types of jobs, but little to no benefits. And then there is the matter of finding the next gig.

Contract work is not my first choice, but I could imagine that if I were younger it might be. If a coder can plan it just so, he could make a comfortable salary for a year in six or eight months and then take the rest of the time off. But that’s a little too high risk for me.

More down my alley might be consulting work. Consulting companies like CGI or Aspirant hire full-time programmers giving them good benefits and good pay. They send their programmers out on jobs for a month, six, months, a year and a half. When the job is over, the programmer is what they call “on the bench.” You still get paid and maintain your benefits, but you’re not on a job. During this time, you hone your skills, maybe acquire certificates in one domain or another, and basically make yourself more valuable while awaiting your next assignment.

This sounds pretty good to me. You get the chance to try out different things and there is the stability of a full time job. However, there is potentially long-term travel with consulting and I would not be able to do that. A week here or there would be ok, but three months Harrisburg? Not ok.

Then there is the golden goose–full time employment. This is what I will be shooting for come interviewing season. You report to the same building every day, have the same coworkers and work for the same company. Boring you say? Bring on the boring!

I don’t really think it will be boring, and also I want the benefits that a full time position would bring. I want a static environment where I can learn from an organized team of programmers so that I can continue to get better.

I’m open to anything, really, but I’d prefer a steady ship, at least at the beginning of my tech career.

Changing one’s life is a difficult business. Never mind the confidence issues that come with learning a new career. Never mind the mental stress whispering that something could go wrong–all this time and money spent on transition could be wasted. Never mind the drain from the soul-search that brought you to the conclusion that change was needed in the first place. Never mind all that.

The most difficult part of this business is when you realize it’s impossible to do it alone.

Most everyone reading this has a support system of one degree or another. Things are hard, yes, but there are people you can depend on. The worst things in life that you dread are many, many catastrophes away, though in the dead of night they may seem to be breathing menacingly just under your bed.

Right now, my wife and I are paying for me to attend a coding boot camp. It is both expensive and massively time-consuming. I hope to come out on the other side of this with opportunities to command a much higher salary than I did in the past and the chance to do something that I find thrilling every day. But this move would be impossible without layers upon layers of support.

First, there are my friends, some of whom have experience in the programming world who tipped me off to coding and that I might like it. I probably wouldn’t be studying C# were it not for their assurances that I could pull this off.

Then there is my family–both my parents and my in-laws. I try to appreciate the security net that they provide, both to make sure I’m thankful and also to let the stresses about money live in a more realistic place. I’m lucky, it’s true. If something bad were to happen to my wife and I financially, we wouldn’t be on the streets. So I’m thankful for that, and also that they are forever saying positive things and helping out with childcare (I don’t even think they think of it as helping out).

And speaking of childcare…

The heavy-lifting that my wife has done on the home front since my time at Tech Elevator began is heroic. We have an eight-year-old daughter, a second-grader, a tall-for-her-age, blond-haired, kaleidoscope- eyed girl who loves reading, cooking, and pretending she’s a spy (and watching Netflix and eating candy as well). She’s good. She’s kind, thoughtful and strangely honest.

But even a child who is well-behaved requires a lot of attention, a lot care, and a lot of focus when life is trying to pull your focus to the four winds. My wife has a full-time, difficult job. She just began at a new company in October and is still trying to prove herself and find her place at work. On top of this, the childcare that we once split 50-50 has taken a dramatic 90-10 tilt in her direction.

But life at home goes on. We still sit down for dinner, my daughter still attends her girl scouts meetings, her Odyssey of the Mind practice (which my wife coaches), and the myriad other events that populate a second-grader’s life. With all of these extra stresses, life goes on and life goes on in a good way.

There are many benefits to challenging yourself. Hard work usually pays off in one way or another. But one benefit of pushing yourself is often over-looked: only in the trenches do you realize the size of the army behind you.

Let’s talk about side projects. 

It is customary for hustling programmers to be working on something on the side. A “passion project,” it’s often called. Several students in my class are developing games as passion projects, one is developing a grocery shopping app, one to do with fitness, one  hyper-specific project is focused on the buying and selling of unique Magic the Gathering Cards. 

While enduring the travails of interviewing, we are told that the interviewer will most certainly ask us whether there is something on the side. They want to see that we are interested in coding, not simply as a money-making venture, but as a way of life. We don’t necessarily have to have a working version of our project, just a promising idea that drives us in our off hours. 

I have had an idea since before the program began, but it was so dependent on databases that I haven’t really been able to get a foothold yet.  Now, with the knowledge obtained this week, I can start the seeds of my Book Recommendation App.

Yes, there is certainly technology out there on the web that can take your past literary purchases and highlight other books you might want to buy. My idea is to be a bit more personal. I will take my fifteen years of book-selling experience into account.

It became clear to me some time ago that, although I have read extensively (over a thousand books, give or take) I do not recommend extensively. Because of my career background, people often ask me what they should read. But instead of taking into account everything I have read, I generally recommend the same four or five books over and over again.  My App would solve my lame recommending skills through databases.

I plan to make a survey to be completed by the user. Then, they will be returned recommendations only from the books that I have personally read and stored in my database with a one or two line description of why I think they would like it. It will be more like a friend tipping you off on what to read rather than a giant robot under the sway of Amazon.

For this, I need a database. And now, after this week, I am finally equipped to build one. 

In many companies, the person who makes the most money is the database manager. On our fourth day of learning database, I learned why. Unlike almost anything else dealing with computers, there are things you can do to a database from which there is no coming back.

Today we learned about inserting, updating, and deleting. When you perform any of these functions, the ramifications are forever. There is no undo button to travel the programmer back to the time before the database was changed. If a client tells you delete certain files and then, the next day, tells you he needs the information back, it’s too late. It’s gone.

The reason for this is that there are databases so large (think Amazon, Facebook, ect) and which have so much information and so many transactions, that they could not keep legitimate records if nothing ever went away.

Conversely, very few things are ever deleted. The challenges in corrupting a database lie mostly in inserting information and updating it. But it is a rare day when something is erased from a database simply for the sake of erasing.

There are two reasons for this. The first is what I’ve already been talking about: deleting data is risky business. What if you need it again in the future? The second problem is slightly more nefarious. Data, it turns out, is money.

When you opt to stop receiving a monthly email from the gym to which you used to belong, you don’t get deleted from their database. Same thing when you change your shipping address with Amazon. That old one is still around. And when you cancel Netflix (I don’t know why you would actually do this, but for example’s sake) they keep your info forever. It’s their currency.

Instead of deleting, a bit key is included with each customer. When you decide to quit your relationship with a certain company, they flip this key to its off position and you are included in the monthly emails no more. But you aren’t deleted. You’re still there, in a dormant state, waiting to be turned back on, mined for information, or sold to the highest bidder.

Flipping the key to the off position is often referred to as being deleted, but it’s not the same. Not the same at all. The company still has it and will still use it in one way or another.

So, as Tom says, when Mark Zuckerberg claimed to Congress that he deleted his customer’s information when they quit Facebook, database managers from around the world pointed at the screen they were watching on and shouted “Liar!”