Walking the Mobius Strip

Bringing Text To Life

During my senior year of high school, I had lots of friends who were in programming courses. They would all come around during lunch time, and chat amongst themselves about the class they just had, or the homework/project they were all working on. I had always been able to understand how to use computers, user interfaces always made sense, even text-based things, like IRC, seemed to just click. However, what they were talking about always seemed so cryptic. I would pick up keywords here and there, recursion, iteration, index, loop. I was never able to make sense of the content in between those, but I didn’t really care to.

Towards the end of that year, a few of my friends who had been in a robotics club (don’t ask me which one) had a final project. They had built an underwater robotic platform, which would do something or other. A few other friends of mine who weren’t involved and I went to hang out with them while they were doing their “final” testing. Everyone else was excited about the robot, how cool it looked, how it could go underwater without short-circuiting. I, on the other hand, was amazed by how they actually made it move. How they were able to type up a text document with a few curly brackets, and a few keywords, and then voila, the thing would move!

Sisyphean Pursuit of Understanding

The concept that writing text could cause things in the real world to do something sat in the back of my mind, piquing my curiosity ever so slightly. It wasn’t until I had taken a digital design class (which happened to be my first class with programming in it) at a local community college that I began to understand how I could use code to change things.

The digital design class went into the very basics of Verilog/VHDL, and how to implement solutions on an FPGA. We did “simple” things, like make an adder, or a counter, or a simple vending machine, and used a few libraries provided by the professor to display some numbers on a seven segment display. Nothing too crazy. However, I finally squashed the fly which was buzzing around in my head for the past few years. I had written some code, and seen a change on the development board. I finally understood, somewhat, how this whole software thing worked.

I thought I had closed the door on that question and could move on. However, that door led to an entire hallway of others. Whenever I felt that I had answered some question I had, it merely led to more questions, more things that I wanted to look into, more nagging feelings that I don’t understand things as well as I could. So I began closing these doors the best way I knew how, doing more.

Paying Dues

I started to take any opportunity I had to write programs, automate tasks, or just toy around with fun concepts. I was lucky enough that I had access to different means of getting new projects to work on. One of these being that my parents had a website design company, and had been only providing static solutions. After I had told them about what they were missing out on by not performing just a little work on the server side of things to serve more dynamic content, they tossed a few different projects my way. These were real projects, with real customers, with real needs. I was shielded somewhat from dealing directly with them, but I got to work on things.

After a little bit of time working on projects my parents' company could provide, I found a job in IT. I had mainly been tasked with doing database administration, as well as gathering/massaging data for report generation. This essentially meant that I was given weird things to try and extract from our database, and thereby beefing up my SQL chops. I began to start seeing the amazing world of databases, and the plethora of benefits they add to many different solutions.

Following my stint in IT, I moved over to some embedded work, writing software for solar powered solutions. This was a whole new concept, in which I didn’t have the “limitless” resources of a full powered workstation. I began to see how to get around limitations in systems, and make better use of what processing power or memory I did have. For example, I had to use approximations for averaging, or tricky integer math to get correct precision without overflows.

We need a medic! And an Architect!

After a few more jobs, with varying aspects of software design, I came to a position at a semiconductor company. There, I was working on characterization, qualification, and verification of new products, and did a lot of a lab work. I also worked pretty closely with test engineers, who would run a huge suite of tests on every device on a silicon wafer (thousands of parts). This obviously led to a lot of data, and the need to not only understand it all, but to boil it down to the important bits and communicate that to management.

The tools the team were using were written by someone who had tried to get something done. They seemed to know how to write code, but just didn’t look into all the different solutions out there, or maybe the solutions just weren’t available at the time of their writing the code. Regardless of the reasons, they needed a makeover, and it was all in my wheelhouse, so I took a stab at giving their tools a much needed revamp.

I was in that position for a few years, and I never stopped working on those tools. Every time I had fixed one problem, there was a laundry list of other things to do. If I had ever whittled it down enough, I would go back and re-update the older tools I had fixed, to make use of new information, frameworks, architectures, or methodologies I had used since I wrote those. There was a constant stream of additions, which started to hone down the overall architecture of the tool suite. This meant that I was constantly evolving, and learning how to plan for larger, ever changing, projects. Software architecture started to become something to focus on for me, as I didn’t have any more one-off projects, but long-term and vastly interconnecting features with more and more customers (all of which were internal, but still customers).

Listening to Smart People

Most of my software design journey had thus far been comprised of me learning how to do things, and making things work good enough. I had read a few things here or there, mainly just articles on how certain people implemented some aspect of their design, or opinions on different frameworks. This was mainly due to the fact that all the friends who were in the position to talk to about this stuff either didn’t have the experience (they started learning things after me), or just didn’t care enough to talk about it. At my workplaces, I usually was one of the people with the most experience programming, either greatest depth and/or widest breadth.

At the time of writing this, my team at work falls into that same category, where not too many of my cohorts have much experience putting fingers to keyboard. However, this team does work closely with engineering teams who are very technical and many of them have extreme amounts of experience in software development. I’ve been lucky enough to glob onto them whenever possible and try to leech off as much knowledge as possible. Inviting myself onto pet-projects they have, or imposing my projects onto them. Essentially I just want them to tell me how I’m doing things wrong, because I’m always assuming I’m missing something.

Having high visibility with these technical teams has opened my eyes to the more formal aspects of software design. Giving names to things which I just picked up on my own, and shedding light on other architectures and philosophies. After each talk, I feel as though another layer of wool has been pulled from over my eyes, and I can see things a little clearer. Of course, the same problem occurs in which I learn one new skill or idea, and then the rabbit hole leads to ten more.

From Whence It Came

After years of doing and learning, there is always more to that I find out about, or am curious about. Always new avenues to go down and investigate. Especially with the ever changing world of web development, where frameworks come and go, the old getting replaced with the next big thing, there is never a dull moment.

Luckily, there is never a shortage for information, and there is a plethora of ways to learn whatever you want. Whether it be through open courseware from universities, online code academies, reddit, talking to coworkers, or just random google searches, understanding is always waiting.

I’ve been walking along the path to trying to become a better software designer, programmer, coder, and I always feel as though I’m just at the beginning of it all. Looking at that robot, and just thinking, How does that work?