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!”

We continued on with databases today and it has begun to be more complex. Whereas before we were dealing with one or two tables at a time, our exercises today dealt with over ten tables, all relating to a fictional DVD store (which I assume has gone out of business circa 2010, like all over video rentals stores. I miss you BlockBuster.)

We were assigned both pair programming and solo exercises. For the pair, I was with Diane, the only woman in the .Net class. To say that Diane is an overachiever is an understatement. She has children and since I have a child myself, I can relate to the chaos parenthood can add, even when you have a significant other helping you out.

Diane talks regularly with her children on the phone during breaks. She also keeps a part-time job as a fitness instructor at a gym, sometimes working till nine or ten o’clock after a twelve hour day of coding. So, already, you can see that this is a busy lady.

But wait, there’s more!

While working together today, I overheard Diane talking on the phone about buying a large amount of stickers. When I inquired about this, Diane revealed that she is also currently running for political office. She’s in the middle of a campaign to get on the McCandless City Council.

Two thoughts occurred to me upon receiving this news:

1. I’m not sure what type of time commitment is made when one runs for office, but it can’t be small.
2. If the good people of McCandless don’t elect Diane, they’re insane.

So, this time next year, Diane very well might be a programming fitness expert with a kingdom of her own just north of Pittsburgh. All hail!

After another smooth day of studying databases, I went out with a couple of the other Tech Elevator Students to a Tech Meetup.

There is an amazing network of programming groups throughout Pittsburgh. The more I look into it, the more I am amazed at how strong and minutely detailed these groups are. This meet up was hosted by Steven Hook, the organizer in charge of the Pittsburgh .Net User Group.

Since the database homework has been so freaking easy, we were able to cut out at 4:00. I went with Craig, my table-mate whom I’ve written about before and Jason, a tall, former-chef versed in many things food and video game-related. We grabbed a drink at Ten Penny downtown and then headed over to the Microsoft offices in the Strip District.

As you might guess, the Microsoft offices are amazing. Everything is clean and futuristic yet somehow homey–imagine the Enterprise, but as a cruise ship. The meet up was in a conference room to the left, screens everywhere, multiple plugs at every table, a view of the Monongahela and the Fort Pitt Tunnel from 14 floors up.

And there was pizza!

A company called Jarus bought the pizza and sponsored the event. The co-Founder, Bala Kumar, spoke to the group and I was able to talk to him personally after about his business, which builds software frameworks for the insurance industry.

The main speaker was a young man named John VanSickle. He spoke about SignalR, a library for Asp.Net concerned with hubs and messaging. Some of the talk was over my head, but I was able to follow the code for the most part and definitely found it interesting.

I plan to go to more of these meetups in the future. I think I enjoyed it because it was specific to .Net and I will continue to target C#, .Net, or particular companies that I’m interested in, rather than just hitting the meet ups when I have time. With a little research, these events are definitely worth your while.

We began learning a language called SQL today (pronounced “Sequel”) and it seems too good to be true. As far as I can tell, there are no loops, no switches, no mind-bending access modifiers, getters, setters, or constructors.

SQL stands for Structured Query Language. It is the computer language used to communicate with data bases. It’s a declarative language, meaning that you’re not trying to tell a computer what to do, but what you want from it. In C#, I had gotten used to telling the computer to loop through a list looking for certain variables with certain qualities and then to display them in the way of my choosing. SQL’s not about that life. SQL’s a no drama language.

For example, in C#, if we tried to find cities in Pennsylvania with a population over a million, it would be two for-loops, probably, going through each list to find the information and a “Console.WriteLine()” to write it to the console. Maybe ten lines of code.

In SQL, it might look like this:

SELECT city FROM list WHERE population > 1000000

That’s it. It’s practically English.

To me, C# is a language that you must speak at a high level to do anything at all and SQL is like talking slowly and loudly because you think the computer can’t understand you. It reminds me of going to Costa Rica and subjecting the Costa Ricans to my terrible Spanish. They can understand me as far as ordering a beer or asking where the bathroom is, but we’re not going to launch a rocket to the moon with this level of communication.

I’m sure it will get ten times as complicated in the coming days, but as for today, it was the easiest homework we’ve had in 21 days of difficult homework. Thank you for keeping it simple, SQL.

It wasn’t easy.

In the summer of 2018, I had zero coding experience. What did I know? Well, I was aware that there was something called HTML and that Java wasn’t just coffee, but that was about it.

I decided to learn to code in August and spent about ten hours a week going through W3Schools Online Tutorials. Then, when I received the prework for my boot camp, Tech Elevator, I did about 45 hours of studying in three weeks, much of it covering the same territory as the W3School material.

Then, on January 14th, it began. My experience from the first month goes like this:

The first week was fairly easy. Much of what I had studied on my own I was seeing again, and for the third time. The next week was a different world. I didn’t count the hours I logged studying code, but it might have flirted with 65. I had a lot of trouble with the lesson on manipulating strings and it took me till Friday to recover.

But recover, I did. The third week was much smoother than the second and I caught up fully. I almost felt comfortable. In the fourth week we covered File I/O and I again got a little turned around. Not nearly as bad as the string study, but somewhat bewildered.

The Vending Machine capstone at the end of the fourth week was the hardest thing yet, by a good margin. My partner Argun and I worked for 10 hours on Thursday, 10 on Friday, and another 7 today (It’s Sunday. We went in on Sunday. Props, Argun.) And we still have some loose threads to sew up.

But though it was the most difficult assignment, it wasn’t a bad time. For the most part, it was fun. There were frustrating moments, but they were overshadowed by the glory that erupted every time we figured something out and Argun proudly turned from the computer screen to shake my hand. Each time we thought of something clever to add to our Vending Machine software it was like we had reinvented the wheel.

Here are some lessons learned from one month in a coding boot camp:

• You can retain more than you think. I was amazed at the long-forgotten lessons from weeks one and two that came to the surface of my mind when I needed them.
• Get good at Googling code. Everyone does it. It’s a skill just as much as learning a language.
• Learn from everyone. I’ve learned from every person I’ve been paired with, whether they were further along than me or I was further along than them.
• Turmoil is the bane of focus. Be happy with your successes and try not to get too frustrated with your failures.
• Know when to walk away. It’s easy to stay on the wrong path if you never stop running. Often after stepping away to eat or play a game, an impossible task becomes quite possible.
• Don’t trust your ego. You know a lot more than you think you know when you’re feeling down. And you know a lot less than you think you know when you’re feeling confident. The truth lies somewhere in-between

One month in. It wasn’t easy. But I am truthfully looking forward to doing two and half more months. We start databases tomorrow and I can’t wait to keep adding to the database in my brain.

I’m in a daze right now. A concentration daze. My mind has been squeezed for two solid days and there is still so much more to do.

Argun and I were off to a good start on the second day of our Vending Machine project. We had nearly all the basics functioning pretty well by lunchtime. We had each agreed that we could work till seven. After lunch, with six or so hours stretching before us, it seemed likely that we were going to finish without a weekend trip to Tech Elevator.

Then reality set in.

I ran into a problem with dispensing the change. We had to return the dollars as numbers (no problem) and the change in coins (big problem). I wrote the War and Peace of C# Methods trying to solve this issue. It’s not what you would call elegant. After two hours and a lot of tweaking, it pretty much worked. But it took quite a toll on my mental well-being.

While I was doing this, Argun struggled on another piece of the code. We teamed up on his and got that end working too. Eventually.

Then the real fun began.

When two programmers work on the same piece of code at the same time using two different computers, a version control system must be the go-between to merge all the work into one piece of software. The version control we use at Tech Elevator is called Git.

Git is tricky. It’s often said that if you become good with Git, everyone will love you at your job. Another way to say that is, Git is a pain in the ass and everyone hates it.

Every time Argun and I merged our code, half an hour was spent untangling the mess of error messages and duplicate code showing up in curious places all over the program.

We’re meeting on Sunday to continue work. If all goes well, we have two to three hours of work. If things go poorly, we’ll work for five or six hours and still have to query Tom on Monday.

One month in, two and a half to go.

Today we began a capstone, the first of three large and arduous projects that we will be assigned throughout the program. We are being tasked to make software for a vending machine. In my mind, the challenge seemed pretty manageable.

That being said, the first day was rough. We were randomly paired and I drew Argun, a high-energy programmer about ten years my junior who is always smiling and goes with the flow. Craig sits on my right every day and Argun is to my left so we are pretty familiar with each other and this paid dividends when trying to communicate over the architecture of the program.

We ran into some trouble right away and it got pretty frustrating. We were given a text file that contained the names, prices, and types of food in the vending machine. We had to import this file and then get the data into a state where we could manipulate it and put it where we needed it to be to make our software work.

This step was one in about a hundred that we need to complete. We were given the task at 10:30 and by 1:30 we had basically nothing. We couldn’t get the data out of the file in a way that was usable. We were stuck.

We eventually got some help from Andrew who tipped us off on how to use a piece of code called a Switch to trick the names of the vending machine items objects, instantiated and ready for purchase. If it sounds complicated, that’s because it was. At least, it’s complicated for our current skill level. Most of the other teams got stuck in the same place as us. Maybe we’ll look back in a month and chuckle about how little we once knew. For right now, there’s no chuckling.

After we got the data all sorted, we made good progress. We were both starting to fade around 5:30 and decided to call it quits. The vending machine is due on Tuesday, but we will be assigned new homework on Monday, so we really need it done by Sunday night.

As it stands, Argun and I have a stocked vending machine which prompts a user to insert money. The machine can take the money and increment it in a balance and display that balance for the customer to see. Not bad, considering a good portion of our day was spent spinning our wheels on one single problem.

If everything goes perfectly tomorrow, we could be finished by six or seven o’clock. Though I would say the smart money is on me spending my first weekend at Hotel Elevator.

The schedule was full for the monks of Tech Elevator today.

It went like this : a lecture from nine till noon, a career discussion led by our third-man teacher Andrew, focusing on coding-adjacent jobs, meetings to review our resumes with Caitie, another panel, related to the first in that it was populated by people who are in coding adjacent jobs. It was nearly six when this last panel ended.

Know what’s missing here? Time to do three to five hours of homework. But it was assigned. I’m not complaining. Just having a Wednesday drink after focusing intensely from 7:00am till 7:00pm.

I was intrigued by both panel discussions. Andrew’s talk covered what we can expect as Junior Software Developers and the path forward in the next four to seven years. He talked responsibilities, life-styles, money–a lot of the subjects that we were all curious about but too afraid to ask.

The panel of professionals dove-tailed well with Andrew’s talk. There was a quality assurance engineer, a security expert, a project manager, and a woman with the rugby-flavored job title “scrum master.” They were all fascinating in their own ways.

The project manager had taken six years off to raise a family and self-taught her way back into a tech job. The scrum master had majored in dance (dance!) in college and managed to find her niche in the industry. The security expert, as you would expect, had several tales of rascally derring-do as he made his way to security professionalism through harmless hacking escapades. But the gentleman in quality assurance captured my attention the most.

I wrote before of my infatuation with test driven development. That’s his thing too. But what really caught my attention was when he discussed building a custom framework. His team looked at what the software developers were typing over and over and made a framework of classes and methods to make them faster. Call me crazy, but that sounds like a good time.

I spoke with the quality assurance engineer after the talk. He seemed really informed and personable. He may be at the matchmaking with Tech Elevator and I hope to meet him again in that capacity. But for now, back to my drink…