"Lost and Found" : Part 5 - Turbo-charge your career and avoid stagnation

Turbo-charge your career and avoid stagnation

The "Lost and Found" series comes to a close. Previously, in Part 4 I talked about the importance of unit testing your code. As the final chapter in this series, I want to talk about my most recent struggle: career stagnation.

There have been a handful of moments in my career where I felt I had plateaued. It was a point at which I wasn't learning very much day to day. The moment that realization set in, work became a grind (at least for me). Day in and day out, it was the same old routine. I don't know about you, but I love learning new things. It's what gets me up in the morning and keeps me up late at night. If I'm not learning, I get depressed and lazy. While this alone should be enough motivation to avoid falling into this lethargy trap, there's another negative side-effect. Plateauing in your career usually means you stop moving up, or lateral, or anywhere. If you're happy with that arrangement, then read no further. However, most of us want that next promotion, that next client, or that fancy senior developer position at [Insert your dream company that may or may not rhyme with moogle here]. Reaching those goals is almost impossible if you hit a ceiling and fall short of their requirements1. Even the most vaulted developer at Facebook isn't going to be kept around for long if they stop learning. The software industry just moves too quickly and will leave you in its dust in a nanosecond if you can't keep up.

So what are you to do? It can be hard working a solid 40 hour week while juggling any number of other responsibilities like family, a significant other, children, or side hobbies. How are you expected to fit in career building on top of all that? Well, the first step is deciding to make it a priority. Many people complain about not having enough time, but time isn't the issue. We all get 24 hours a day to work with but as evident by the likes of Bill Gates, Steve Jobs, or [Insert your favorite software idol here] it is possible to reach heights previously unfathomable. The only difference is that they made their goals a priority. If all this sounds like hogwash to you, let me ask you to take a moment and think about what you prioritize your time on. Go on, I'll be here when you get back. Got it? Good. Those things are a higher priority to you than the things you're not spending time on. But you do them and find time somewhere in your busy schedule. If you're saying that TV isn't a high priority, then why are you watching it?!

The second step is easy: Start reading books related to your career, or listening to audio books while you exercise or during your commute. All you need is 30 minutes in the morning and 30 minutes in the evening, every day. Do that and you'll burn through about one book a week which means 50 books a year. Compare that to the average that most adults read, which is 1 book a year, and you'll be far above the game! 50 books a year is the equivalent of a Ph.D in your field every single year. Can you start to imagine what kind of effect that would have on your career and your income!? There's a whole list of other things you can do as well, but I think the first two steps will suffice in getting you started. If you're curious about what those other things are, I highly recommend checking out The Miracle of Self-Discipline by Brian Tracy.

photo credit: Speeding ticket via stavos cc

  1. Unless, of course, you already work there and are living happily ever after. Good for you! 

"Lost and Found" : Part 4 - Software development in practice

Software development in practice

The "Lost and Found" series continues from Part 3 with a deeper look into the practice of software development and the kinds of wins and losses I've seen along the way. Rewinding back a bit to my days working in technical support, I remember how dreadful it was trying to troubleshoot something that appeared to be a bug in the software. Many times we had no way of knowing what the cause was or where it stemmed from. The primary reason for this, as you might guess, was that we had very poor error handling. On top of that, our code base had little to no logging. If there was any error handling at all, it was done by passing around an error message in $@. For those unfamiliar with Perl or how it handles errors, $@ is meant to store the error message from the last eval() operator; however, many Perl developers set it manually when an error occurs. I can't quite understand how this was ever standard practice. The obvious issues with this approach are that it gives very little detail about the error other than a string, the message can be easily clobbered or overwritten and worst of all there's no stack trace or information about where the error was originally set. If you were lucky enough to get a valid error message, you'd have to grep the code base to find where the error got set, hoping that there were only a few places to look.

With that bit of backstory out of the way, you can imagine how much of a win it was to finally get some logging in place. One of the first things I helped with when we started our software rewrite was to implement Log::Log4perl1. I think this, above anything else we did, saved hundreds of developer hours. I can recall numerous occasions where I was working in very complicated parts of the system and discovered defects within seconds, simply by having detailed DEBUG and ERROR logging noting the module, method, and line number. This was long before we had given any serious consideration to unit tests, but despite the manual effort, it was a huge step up from before. Of course, the one caveat with this approach is that after months or years when you've hardened various sections of your code, the logs become cluttered with useless messages. Things get to the point where sifting through the log is like trying to decode The Matrix. This makes it difficult to find bugs in more recently written code. After a long enough period of time, those DEBUG statements should be removed or changed to TRACE statements instead.

So, logging is great, especially during the early stages of development when lots of testing/debugging is going on during integration testing. What's better? Unit tests. I've heard a lot of people talk about unit tests and many of them have varied definitions of what they are and what they are not. The specific definition is going to depend on personal preference and what is required of the project you're working on. Regardless of the definition, however, some key principles should apply; small in scope, done by the developer implementing the code, and fast. Some people refer to unit tests as if they were integration tests and use the terms interchangeably. I think this is a mistake, if you've got integration tests set up (Selenium, for example), calling them unit tests give you a false sense of confidence in your test coverage. It's a given that having some tests is better than having no tests, but ensuring unit tests are in place gives you finer control and helps ensure modularity, clean interfaces, and encapsulation. This is especially important if you have an MVC or Model-View-Controller architecture.

Which, I believe, leads to one of our largest losses. The lack of unit tests from the start of the project resulted in much of our business logic (Controller in MVC) mixed up with our View code. This means that when we did get around to writing unit tests, it was now much harder. In Python/Django that means ensuring a valid request context. In Perl, it usually means having a CGI instance. It's extra overhead to have to worry about because there's more mutable state that needs to be set up to test a View instead of testing a method in a Controller. We also have a lot of our Model logic littered around as well. This means that for the majority of the code, it's almost impossible to test without having a real, live database up and running. All of these issues ultimately lead to mental molasses that result in developers not writing any unit tests at all. This, I think, is a great argument for having a more TDD-centric workflow. If you attack a problem solution with testing at the forefront of your mind, you're forced to design code in a way that's easily tested.

Not having unit tests obviously results in more developer time debugging, due to not having an early notification if something breaks. It also results in code that is buggy and error-prone. However, the biggest impact is ultimately on the QA team and eventually the customer. One of the slowest areas of the software development cycle is in manual testing. This comes in the form of regular testing of new features, regression testing, smoke-testing, load testing, and penetration testing. This can add up to hundreds of hours of testing for even the smallest of features, especially depending on the number and variety of inputs. It's no wonder, then, that unit tests would save much of this time if said tests can provide a high level of confidence that they cover what needs to be covered. Having unit tests automate regression testing alone would justify the time and energy to implement and maintain them. Just think about the thousands of bugs your average enterprise system can manifest over its lifetime. If every bug had a test ensuring it never occurred again in production, how much time would the QA folks have to focus on other things like smoke-testing?

I doubt any sane developer would refute the usefulness of unit tests. The usefulness is rarely in question. The obstacles that are typically brought up are time and difficulty of implementation. I've already mentioned that implementation becomes much easier if you focus on testability first. Time, however, is simply a matter of perspective. We humans are notoriously bad at estimating time. It's especially bad if that time is split into hundreds of small increments over the course of six months or if that time isn't felt by the person doing the estimation. With unit tests, time put in now saves magnitudes of time put in later. This saved time isn't just for the developer. It's also for the fine folks in QA, Systems, and ultimately for the Customer or Support Technician. All of that adds up.

Let's run through a small example. Say you've got a reporting system that you wrote without unit tests which report the number of calls taken in a day. Now say there's a bug in that reporting system that doesn't account for calls that were transferred to another extension. The customer, at the end of their week, pulls up the report and is surprised at the low call count. So maybe they spend 30 minutes adding up their calls by looking through their emails, or CRM system or whatever. Finally, they come to the conclusion that the report is wrong. They then call support and wait on the phone for 15 minutes before getting to speak to someone. The technician spends 30 minutes troubleshooting the issue (assuming they didn't already know about the bug) before informing the customer. The technician files a bug report. Now say this happens to 100 other customers. Some time later a QA person spends 30 minutes reproducing the issue and filing an engineering ticket to fix. The ticket takes time from the engineering project manager to update the issue, assign it to a developer, prioritize it, etc. Let's say 10 minutes in total2. Finally, the developer gets it, tracks down the code, fixes it and tests it: 1 hour. QA re-tests it before it gets deployed: 30 minutes. These are all very low estimates considering the amount of overhead some companies have in coordinating resources.

Have you been keeping track? Total time spent by all parties: ~105 hours3. The time it should have taken to write unit tests to ensure the reporting system accounted for all types of call traffic: ~2 hours4. It's a no-brainer. In Part 5 I'll talk about career stagnation and some ideas for preventing it.

  1. A Perl implementation of Log4j

  2. This is a very efficient project manager! 

  3. (30 minutes customer troubleshooting + 15 minutes waiting for support + average 15 minutes on the phone) * 100 customers = 100 hours. Then tack on about ~5 hours of internal administrative overhead to find/fix/release the bug. 

  4. Depending on the complexity of the system and how easily the bug was found in the source. 

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