"Lost and Found" : Part 3 - I do not think it means what you think it means

I do not think that means what you think it means

In the post-college world I recounted in Part 2, things are much different than I imagined. At this point in my career, I was working on increasingly more side software projects. Software Engineering, in practice, was still a bit of a black box to me. Since I was working on the support side of the company, I only saw the end product1. Occasionally, our team would have a discussion on the new features coming out and we would conduct various levels of training. However, I still had very little insight into how these ideas or features came to exist. Who defined them? How were they designed? In the end, I was just a consumer of the software and subjected to the end-user experience. Once in awhile, bugs that had existed for years would finally get fixed or features we had clamored for would be released. In reality, though, we weren't the designated end-users of the system; our customers were. Many of the changes were directed at customer reported issues, which is generally good for business. Much of my frustration from working in support was dealing with this dilemma of not seeing the changes we, as a support team, wanted to see. My desire to switch over to the engineering side of the company was to see if I could help effect change in that area.

To my surprise, it wasn't as easy as I had imagined. The first few weeks on the engineering team were very enlightening. My expectation coming in was to start digging into the code-base, learn the basic development cycle practices such as code-review, team meetings, design discussions, etc. That expectation was not met, and was instead turned on its head. There was a lot more disorganization than I imagined possible, which was bad for the company overall, but a great opportunity in waiting. You see, before I switched departments, I had been promoted over the years up to a support leadership position managing our most skilled technicians. I had a knack for process control and here was a great chance to institute a fresh process from the ground up. Instead of diving in as a software developer, I steadily fleshed out my role as a Scrum Master. I was even sent off to get certified. There was a lot of work to do. My arrival on the team happened to coincide with a total system re-implementation of our operational and business support systems. We adopted scrum and agile practices with a fervour and we had the management and team support to make it a success.

Scrum didn't solve all of our problems though. While we delivered the project with much greater success than previous projects, we still missed deadlines and budgets. Despite those downfalls, the thought of trying to meet those guidelines in the pre-scrum era were unfathomable; both to the whole team and to me. It was a very satisfying experience overall. However, as we neared the remaining few months of the project, my desire for technical and intellectual problem solving started to gnaw at me. I had a great sense of proper process control, but it wasn't fulfilling enough to keep me content. I eventually stepped down from the Scrum Master position and into a dedicated software developer role. I felt I could affect a much greater influence on the development practices by rising to a leadership role within the team. That goal has certainly driven my style and design decisions over the last few years and continues to be a motivating factor for doing things as close to the right way as possible.

Once we released our two years of effort to production, everything changed. Scrum became hard to maintain within the tightly controlled QA and release processes we had developed over the years and continued to use. The priority of features, changes, and bug fixes didn't fit nicely into our two week sprints. Various processes were created by various members of the team in order to address issues that came up. The end result worked, for the most part, and got software releases out the door, but ideal of scrum and it's processes became mostly obsolete. We weren't developing in a vacuum anymore. We had stakeholders to answer to that we didn't have before. All of the conflicting priorities made maintaining our agile processes difficult. Early on in the Scrum adoption process, it seemed easy and natural to strictly adhere to the ideal workflow. As reality keeps reminding us, though, ideologies should be applied within reason. Each company, each team, each project all have their own little quirks. There's never a silver bullet that will solve all problems for all cases. Even today, we're trying to adapt and see what works and what doesn't.

Overall, developing production software has been much different than I expected. Long gone are my dreams of creating the myriad of fantastic tools and features that I yearned for while in support. The demands of business, customers, and product strategy have out shadowed those dreams. That is not to say that many of those ideas won't ever come to fruition, but it will likely be by sheer necessity to support our customers and not nearly to the extent with which I had hoped. Resource limitations are much more restrictive than I had imagined and it's through process control and implementation that we can get the most bang for the buck. In Part 4 I'll start getting into the nitty-gritty of the trials and tribulations of the software development lifecycle like QA, unit testing, code reviews, and more.

photo credit: Princess Bride [Motion picture]. (1987).

  1. And lamented about all the things wrong with it (from a technical support perspective) 

"Lost and Found" : Part 2 - PC load letter?!

PC load letter

In Part 1 I regaled you with my first encounter with programming and the bygone era of the early web computing days. Now, I'm going to explain why school turned out very differently for me than the real world. This may seem like a stupidly obvious realization to anyone who has already passed through the gauntlet of our education system, but when you're still in the thick of things it's not as clear. Looking back, I realize how under prepared I was and how much I relied on sheer luck to get by. I was intent on getting a career in software development, without a thought or consideration for any alternatives. I scored pretty high in that area on my career placement exam, I had fun doing it at home, and so, obviously, this must be the one and only career for me. My quest was so blind that I also didn't even consider other schools. I had settled on a university that seemed to be a good fit: Kettering University, and didn't bother with any second or third choices.

Then I got a notice from my counselor about my GPA being less than...desirable. So, I wrote a letter of apology in hopes they would accept my application. Luckily, they did, and I was off to college to prepare for my career! I was finally moving out on my own, on my way to learning how to write real, professional software. The first few weeks were great. I was making friends, taking difficult, but challenging classes like Calculus, Discrete Mathematics, and Introduction to Java. I was really enjoying myself. Many late nights were spent on homework assignments, trying to work out the algorithms needed to get them working correctly. Of course, at this time, I also played an excessive amount of Final Fantasy XI Online which cut into my studies more than I would admit at the time. Programming was hard, the compile, hack, compile cycle was annoying. Calculus was also hard, along with many of my other classes. Then came, what I consider to be, some pivotal moments that altered my life course.

Exhibit A

I was given a Java project in which we were told to write an encryption algorithm that would take some text, encrypt it, and print it out. The second part of the assignment was to reverse the encrypted text back into its original form. Now, these days, I consider this to be a pretty trivial task, especially with the wealth of encryption libraries available in pretty much any language of your choosing. However, this assignment (at least as I remember it) did not involve the use of any pre-existing libraries. We had to implement an encryption algorithm from scratch. This was only my second semester in computer science, and I hated this assignment. I never did complete it successfully. I was able to encrypt text well enough but never succeeded in being able to decrypt the content. Strike 1 in my plans for a career in software development.

Exhibit B

The looming expenses of the upcoming academic year were starting to worry me. My tuition for that first year came out to around $24,000 including room & board, and I was barely able to afford it1. The whole reason I had settled on Kettering was because they offer a great co-op program. The idea was that you would swap between school and co-op every three months. I had been looking for a co-op position since the start of the school year and nothing had come up. The few interviews I had had all required one critical skill that I failed to satisfy: Visual Basic. The chicken-and-egg conundrum was that Kettering did not offer a course in Visual Basic (as far as I knew at the time). Lovely. Strike 2.

Exhibit C

A movie called Office Space was released a few years before I started at Kettering that cast a very negative (but humorous) light on the software industry and on the mind-numbing conditions of working in cubicles. I absolutely love that movie, but, quite honestly, I was terrified to actually get a job in software if I was going to end up stuck for years on end in a cubicle patching bank software. It just seemed so mindless, and so far my experience in school was exactly that. It was far different than the fun I had had sitting in my room at home, hacking away on something I got excited about. Strike 3.

It was because of this third strike that I began to consider transferring schools because I was going to go bankrupt without a co-op. And, I thought, I might as well change my major while I was at it since the whole computer science thing wasn't really turning out to be my cup o' tea. My thought process was that the reason I used to get so excited about programming was because the projects I had worked on had a much more visible outcome. Graphics, web design, user interactivity. The assignments I was being given in class were all back-end algorithms, where most of the work was being done behind the scenes with no visible output. Following that line of logic, I decided to switch my major to Graphic Design. I switched schools too, to a local community college called Baker (much cheaper tuition!).

I had fun for a year before I realized how bored I was. I was really good at it, but it just didn't have the same gratification as working out the solution to a complex problem. I sought the advice of one of my graphic design teachers about what I should do. Her recommendation was to try something more challenging, naturally. I went home that evening and dug into the course curriculum offerings that Baker had to find the major that would suit me. Web Design seemed to fit the bill nicely. It had front-end components with a visual output, it also involved back-end programming that would challenge me. I thought I was all set!

Sadly, it was not to be. Only a year into the program, Baker canceled their Web Design degree. Thinking about it now, that seems kind of crazy and extreme. It's possible that I misunderstood what that cancellation was truly about, but nevertheless, I ended up switching schools and majors yet again. It was the proverbial last straw on my camel's back.

Now, let's fast-forward through four years of changing schools and majors, getting married, and moving from Michigan to California. I managed to land in an IT related field working as a support technician for a company that sells business phone systems as a service. This was a fantastic job. So much better than anything I had before, and stable enough as a career choice for me to forego finishing my degree. Over the course of a few years, I steadily rose through the technical support ranks, earning experience and knowledge as I went. It was around this time that my intense passion for programming began to resurface. Out of necessity, the job required knowing a lot about our software which was primarily written in Perl. It was also a great boon to be able to write or hack together quick support scripts to help with everyday, mundane, tasks.

More and more, each day, I was spending increasing amounts of time and energy on programming various things and getting excited like I used to back in those early days. I was slowly planning my transition to move over to the engineering side of our company. There were so many good ideas I had that would solve problems we were dealing with in support. I wanted to be the one to solve those problems through software. Of course, my wishes were eventually granted and I was able to change positions.

When I finally found time to reflect on my history with software development, I realized that being taught how to program is not the same as discovering how to program. This, I think, more than any other is why software in school is so different than software in a professional environment. In school, I was being told about problems that needed solving and was told to solve them. The problems were not my problems and thus were not important. It wasn't until I started encountering problems that were important to me, that programming solutions to them also became both important and interesting enough to invest my time in. It was in the thick of that problem solving that I discovered how to program. Very fluidly and organically.

The best advice I can give to anyone wanting to get into software development is to go find a problem that you're passionate about solving and go solve it. The joy of writing words into a computer that solves a problem is amazing and well worth the effort. In Part 3, I'll delve into what my first experiences were like in engineering and the kinds of challenges that came up that I didn't expect going in.

photo credit: GYLo via photopin cc

  1. Read: I took out a ton of loan money to pay for it. 

"Lost and Found" : Part 1 - From Dungeons & Dragons to HTML

Dungeons and Dragons

My descent into the world of programming started at a pretty young age. This was back in the early days of the world wide web. Internet giants like Facebook and Twitter weren't on the scene yet and Google was just getting started. It was a time when GeoCities was the third-most visited site on the internet1. At age 13 I had been hooked on technology for some time, having already gone through a few flavors of Windows2. I didn't start getting interested in programming, however, until after Windows 98 had come out.

The computers and the advancing technology of the internet were awe-inspiring, but they were not what got the programming ball rolling. It was, oddly enough, a chat room. A Dungeons & Dragons chat room, to be precise. It was something my cousin and I used to do in our spare time. We'd log in, enter chat, and roleplay our chosen characters with other users. During one such encounter, the mage I was talking to typed red letters in the chat window.

I was amazed by this. I knew that web pages had some kind way to format text, but I had no idea how to apply it to chat. There were no formatting options available that I could see. So, I inquired about how to turn my text red3. It wasn't CSS or Markdown or any other similar method4. It was just plain ol' HTML. Just type <font color="red">, type your words, and close it with </font>. Simple enough!

Little did this random internet stranger know that this revelation would start me on a path that would forever change my life and how I viewed the world. It wasn't long before I started digging into the rest of the HTML 4.0 specification, learning CSS 2.0 and JavaScript5. Somewhere along the way, I stumbled across Perl and began tinkering. I was still a big D&D fan and spent a lot of time on www.netdragons.com playing an RPG called Vagabond's Quest6.

I loved the game and wanted to make my own version. My very first programming project was born! I learned a lot, but looking back I'm shocked at how little I knew. As an example, I had no concept of databases back then. My saved game data was a text file with each line corresponding to a character and each value separated by a vertical-pipe (|). Perl is great at parsing text, so it did have that going for it!

As an outcome of all these experiences, I piqued the interest of my younger brother, launching him on his own path towards programming as a career and I had settled on a major for college: Computer Science. I didn't know it at the time, but I was not prepared to major in computer science.

Not because I wasn't smart enough, or interested enough, but because I did not fully understand what it was about. Computer Science is pretty self-explanatory, but the experience of school vs real world application are entirely different and I was about to learn that the hard way. I'll explain what I mean in Part 2. See you there!

  1. RIP GeoCities

  2. Windows 3.1x and Windows 95

  3. Out of Character of course. 

  4. Markdown didn't even exist yet. 

  5. Back before there were frameworks like jQuery or AngularJS. Back when everyone loved to hate JavaScript. 

  6. Sadly the site no longer exists. 

"Lost and Found" Series : Lessons Learned

Lessons Learned

My software development career has been a long and insightful journey. I've learned a lot in a short time and I'd like to share my story in this five part series I'm titling "Lost and Found". It's a tale of my meandering past; highlighting the early days of my fascination for code and of my going astray, only to return, years later, with an even greater passion. There were a lot of mistakes made, but also lessons learned. Good ol' Einstein was right when he said "A person who never made a mistake never tried anything new".

I hope you follow along as the series unfolds over the next several weeks. The software industry has such a fascinating landscape that changes almost daily, and at an ever increasing pace as technology blooms. I'm amazed how different the technological landscape is now compared to years ago when I got my first computer and how different the world is because of it. Working professionally at a software company is very different than I had imagined growing up, with more problems to solve than software alone can tackle.

Stay tuned for Part 1!

photo credit: Brett Jordan via photopin cc

First post

It's taken me awhile to get around to it, but the site is up and all pages are in a mostly complete state. There's a lot more functionality I want to add like comments and an RSS feed but this is a good start!

I'll be posting articles about once a month to start with as I finish out the site, and we'll see where to go from there. Happy coding!