Tip-toeing Back into the Development Waters

Tip-toeing Back into the Development Waters

Profile image
Kevin Koperski
Mar 07, 2016 • 4 min read

Some time around 2011, I stopped writing code. I was a full stack .NET developer with a preference for front-end work. That meant HTML, CSS, and Javascript at the time, with a bit of AJAX (and awful .NET ajax containers).

Our tiny company had doubled in size. Our core product (a multifamily apartment marketing tool) was taking off. I had taken over design responsibilities, because I was decent at it, and being the primary front-end developer it was easy for me to tweek designs as I built. But one thing lead to another, the team grew, I took on management and executive responsibilities. As a result, my days as an everyday coder unceremoniously, and only somewhat intentionally, came to an end.

Flash forward five years. I’ve dabbled in code here and there. I’ve done a bit of Ruby development, a bit of iOS development, and several Hello World Android tutorials. Most of what I learned faded quickly, because I never progressed far, and I didn’t practice often enough to truly learn and retain.

I started writing code, like many people my age, as a kid in the 80s with a personal computer. The Apple IIE was popular, as was the commodore 64. Me? My dad bought a Texas Instruments 99 cartridge based system. My first lines of Basic went something like this:  Line 10: Print Kevin, Line 20: Goto Line 10.  Eventually I added For loops and color changes, and I marveled at the ability to make things happen on my television by writing simple commands.

I played in that world on and off through high school, but venturing off to college in the autumn of 1993 changed everything. We were the first class of freshmen at the University of Illinois to be assigned a unique email address.  The Mosaic browser had been released the year before. Developed on campus, it was the first true browser (as we know them) for the world wide web, and its developers would soon run off and get rich creating Netscape.

I remember lining up at the computer center to be among the first to get a free 3.5 inch floppy disc containing winsocket, a TCP/IP tool, a telnet application, and Netscape 1.0. Shortly thereafter, I was hyperlinking across the web, visiting newsgroups, reading about topics I’d never considered investigating before, and getting an itch to stake my own claim. The next few years became a constant learning process. I skipped half my classes to stay home and build websites. HTML was such a simple, powerful thing. Perl scripts confused me at first. But we had framesets and blink tags and, eventually, javascript and CSS. My first website, a fan site dedicated to the sitcom Wings, earned me compliments from the show’s writers/creators and a visit to a rehearsal at Paramount Studios in Hollywood.

I enjoy building websites and web applications for the same reason I enjoy writing stories and taking photos and making movies. It’s about creating things to be experienced by other human beings. I’m no artist, but I enjoy making stuff for people to see. Computer code and the internet is another means of doing so. Code appeals to both my desire to create for consumption and simultaneously satisfies the logical, analytical side of my brain. Unlike writing stories, where you can spend a day on a paragraph and have no objective way of knowing whether it works well, writing presentation-layer code is black and white. Things either work or they don’t. Sure, complicated javascript may work in one browser but not another, but that’s a different issue. There are myriad ways to write code to do a single thing. Some are more efficient than others. Some use less computing resources than others. But if I want a button to move across the screen when it’s clicked, I write code, and I know right away whether or not it works. The ability to evaluate your work objectively is something artistic fields completely lack.

So here I am, five years post developer life. I’ve been toying with a new idea for a couple years now. It’s a writing-related app. I very much want to build it. I intend to build it. In order to do so, I must learn a lot of stuff.

To that end, I’ve begun to familiarize myself with the technology stack I intend to use. I’m planning a mostly javascript-based stack.

In the backend, I’m leaning toward MongoDB. I’m extremely familiar with table-based relational databases, but I’m not quite up to speed with document-based noSQL databases. I’m not entirely sold on the benefits, but a good chunk of the app I intend to build falls into the document-based db use case. We’ll see.

From there, it gets easier. Node.JS for the webserver and API, which I’ve tinkered with.

And the part I’m most excited about: Angular2 for the frontend UI framework.  The javascript world is a changed beast from the one I once knew. Lots of command line work. Multiple terminals running and executing code and performing tasks. In my day, I fired up a local IIS webserver, it ran in the corner of my toolbar, and that was it. Kids these days have really complicated things, but… I’m learning.

I’ve taken several Node tutorials. I’ve worked my way through an Angular 2 quickstart guide and built a tutorial application. Angular2 is brand-spanking new. In fact, the framework isn’t finalized yet. It won’t be for a few more months. To me, this feels like a head start on something great, especially because it should position me to create an application that works well on mobile devices, even though it will be primarily a desktop tool.

So that’s where I’m at. I’m reading and/or taking a tutorial almost every day. Soon I’ll start building early tests of my idea. These should help me learn the framework while also teaching me best practices for file organization and architecture.

I intend to revisit this topic frequently on the blog. I’m having so much fun with it. It’s challenging and frustrating and rewarding.

Best of all, I’m building. I’m creating. Few things in life are more rewarding.

Also published on Medium.