Dave Powers Codes

My path to becoming a web developer.

On Being a Software Developer

I am a “software developer.” Or, at least, that’s what my official job title says. I suppose I could be considered a web developer just as equally (possibly more accurately). Others who do similar work may self-identify as a programmer, coder, hacker, problem-solver, or a number of other terms.

Some preface their title with their technology of choice (or necessity, depending on their job): I’m a “Rails developer” or a “Python coder.” This may, again, be more accurate, but does your toolset define your work? As you learn a new technology or language, when does it become appropriate to append that on to your title or list of skills?

Many companies also distinguish between “junior” and “senior” level programmers, sometimes with “middle” in between. I don’t think this gives an accurate portrayal of an individual’s skill level, and the category in which a person falls can vary widely from organization to organization. To me they come across more so as H.R. buzzwords. I’m sure there are many senior developers who coast by, while coworkers lower in the company totem pole work much harder in order to prove themselves.

There’s also the notion of being a “real” developer. This tends to manifest itself in developers scoffing at those using what they consider to be “beginner” languages. Today it is easier for anyone to start programming, which should be seen as a good thing. A larger talent pool to draw from benefits all, and allows you more people to work and learn with. Most likely, someone without the talent or desire to succeed will be weeded out.

Titles are really just what you make of them. You could be a “rockstar programmer” or a “Chief Imagination Officer”, but all it does is obfuscate what your work actually entails.

When it comes down to it, all of these people are building things. This could mean complicated things, or it could mean simple things, but building nonetheless. I think people sometimes get caught up in how to cram in as many flashy words as possible when describing what they do, rather than providing a succinct answer straightforward enough for someone who doesn’t identity as a programmer to understand. Marco Arment’s short blog post “Explaining your job” accurately sums up my thoughts on the matter.

Part of my reasoning for writing about this subject stems from my own struggle on how to best describe my abilities. A couple months ago, I started my first development position. On paper, one day I wasn’t a software developer, and the next day I was. But really, I’d been developing software for months prior as I began my transition to a career doing just that; this was simply the next step of the process.

I’d had my own preconceived notions of what a software developer was. How they worked. How capable they were. It forced me to question whether I fit into my own description. I primarily program in Ruby, but I’d wonder “how well do I actually know Ruby?” Some of this self-questioning has shades of impostor syndrome.1

Today, I still don’t quite feel like I deserve to call myself a software developer. Though, in a way, I think this is a good thing; it keeps me motivated to improve, and always be bettering myself. I need to remind myself to reflect on my achievements and how far I’ve come, but I don’t want to ever be content with my current skill set or knowledge. After all, what motivation does the “senior” engineer have to enhance their skills, if someone has already deemed them to be at the highest level?

Going forward, I plan to continue to record my growth during my career. Seeing measurable progress helps to remind me how far I’ve come. Writing down what I did for the day along with any difficulties helps to reinforce what I’ve actually learned. As long as I’m not stagnant, I’m happy.

And for now, I’m developing software everyday. I guess that makes me a software developer, whether I have the title to show for it or not.


  1. When reading this article, I realized that in blogging about the subject, I was practicing one of the modes of therapy.


SpotCheck Has Been Approved

I previously wrote about my reasons for developing my app, SpotCheck, and what I hoped I would accomplish. It has since been released into the wild, and I’m pleased to finally share it with others.

My aim was to solve the problems I’d faced myself while working in video post-production, and I was able to accomplish the main functionality of my initial feature list. This includes creating private projects with different roles for each member, direct-uploading of video using Amazon S3, and leaving a comment referencing a certain time in the video. I was able to accomplish the “time-tagging” feature using Popcorn.js.

There were a lot of challenges along the way, but I learned a lot by running into problems and having to think about things differently. The aforementioned security/privacy roles were tricky, since users can have many projects, and projects can have many users. Additionally, each user will have a specific role for a particular project, which determines which actions they are allowed to perform. A join table I called “Memberships” was used to allow this, which force me to really think about all everything functioned together. For example, I initially was looking up memberships to verify viewing ability, but had to adapt the code to deny a user if the membership was nonexistent, or nil.

I gained a lot more understanding of working with controllers, and how to redirect traffic if the viewing criteria was not met. I also learned more about environment variables and how to properly configure them to avoid sharing your sensitive account information with the world.

For the front-end, I really enjoyed working with Zurb Foundation to style the application. Once you learn the basics of the grid system and how to customize common interface elements like buttons and flash messages, it doesn’t get in your way and allows you to design as you please. Foundation allowed me to create the modal slide-in for the sign in and sing up forms, and also the responsive design on smaller screens, including videos associated with a project.

As I continue to work on the app, I’m planning to incorporate more JavaScript features. This was my first real foray into using JavaScript, and it definitely isn’t going anywhere soon. One specific example, based on feedback I’ve gotten, is that it would be much better (and user-friendly) to have a button to grab the current time, rather than forcing the user to manually enter it. This also eliminates the chance for user-error, which is always a plus.

I’d also like to thank my former coworkers that took a look at the app and gave their very honest feedback. The audience for SpotCheck is smaller than most apps, so it’s very helpful to have some targeted users that are familiar with the market. On the other end of the spectrum, it’s helpful to have inexperienced testers to ensure that the function is straightforward enough. Hopefully I can strike a good balance.

If you’re still reading, there’s a chance you might like to actually check out the application: SpotCheck


Ship It!

As of recently, I’ve been busy finishing up a couple projects that have since been shared with the world my family and limited Internet following. More on those in a moment.

First, I wanted to share a quote that I like, which is an old saying at Apple attributed to Steve Jobs:

Real artists ship.

I appreciate it for its brevity in serving as a reminder to always ensure that your projects come to fruition. There is often very little value, either financially or educationally, in an unfinished project; you need to hit various roadblocks along the way to actually learn. In my experience with these projects, there was a lot of educational value from going through the development process from start to finish. There are so many factors that don’t become apparent until you have at least a working prototype, especially if you lack experience. A lot of assumptions were made about how users would act and what they would expect.

Actually finishing and delivering a project gives one a sense of completion. I love that the development process is ongoing, as I can easily update a project to add a new feature or experiment with a new technology. Getting a project deployed was one of the moments where I felt like a “real” web developer. Having web apps actually be available online seemed to legitimize this identity.

Estimation Station

The first project was an idea I that I had a few weeks prior, and decided would make for a good one-day project during the Ship It! Saturday event at Launch Academy. The idea was to come with a project idea, and developing and shipping it that day.

During the holidays, my family has organized a “guessing jar” game to pass time before eating. Everyone would bring a jar filled with a certain item, and others would have to enter a guess of how many items are in that jar. I was tasked with calculating the winners, and with upwards of 20 jars and players, it got tedious. The work was much better suited to a computer than a human.

I wanted the entering of guesses to be quick, so I only required the organizer of the game to register, and they can then create multiple groups. This would allow the app to be used by elementary school teachers, as well. After all jars and players have been registered, guesses can be entered for each player/jar combination. The winner of each jar can be displayed with the click of a button.

The application is called Estimation Station. I plan to improve the display of winners and add some statistics using a JavaScript framework next, and also customize the interface more.

This project took me a little more than just a day to complete, but I’m glad I took the time to finish it. I learned about using scopes in Rails as a way to ensure that there could be no duplicate guesses entered for a given player/jar pair.

Next, I’ll provide an update on my other project, Spotcheck, which was my breakable toy at Launch Academy.


Accepting Acceptance Testing

I recently reflected on my experiences with letting TDD steer the development path. TDD was employed for unit testing, primarily testing validations of fields, associations between models, and the presences of database fields. Acceptance testing is the next layer outward in the outside-in software development methodology.

Acceptance testing is meant to ensure that the business needs of the stakeholder are met. Tests are generally readable, and with good tests, you can see whether features satisfy the requirements of each scenario. For example, if your application’s main feature and acceptance criteria include “images are permanently deleted after a user-specified duration”, with thorough tests, you can quickly determine whether it passes or fails.

The tests mimic the behavior that a user will exhibit on your site, so it’s up to you to ensure that various use cases are covered. Common scenarios would be the “happy path”, what happens when the user interacts as expected and everything goes smoothly, as well as the inverse, like a user submitting a form with no fields filled out.

Including good acceptance tests definitely provides good coverage, and provides me with confidence that my application is functioning as expected. While it can do a good job of simulating user behavior, it is not infallible. I still think that going through all scenarios manually can be beneficial, if there is time provided to do so.

During a recent test, I was checking for the presence of an error message on blank fields. Testing it myself in the browser, I ran into an interesting issue where a pop-up field was present instead of the expected error text. However, my tests were still passing. I later determined it was part of the HTML5 required input attribute. The RSpec test did not support such a pop-up, and saw the plain text as a fallback. It was a good reminder that cross-browser testing is still important as well to ensure the UX is as intended.

Acceptance testing feels like a natural progression from test-driven development, since it’s really just an extension on the same idea: let your tests (or errors) determine the next action you take. As I practice it more, I can typically anticipate what the failure for a given test will be before running it. It serves as a useful guidance, and I’d liken it to using a GPS for directions on a route that you’re already familiar with; it’s there to make sure you stay on course and confirm that you are taking the right steps.

Starting out with good user stories and acceptance criteria, I find writing the tests to be like a planning stage, which makes the actual implementation that much easier. Making a test pass is very satisfying, especially considering that without tests, you’d have to manually go through all of your tests after every change (assuming you want to be thorough).

I’m reminded of the idea of the “render tax” from working in video production. The idea is that your video project will need to be rendered by the computer at some point in order to be played back smoothly. This can be before editing begins, throughout editing, or at the end during export.

Relating this concept to software development, you would be paying the “testing tax” at the beginning of and during your development cycle. Since the tests are completed upfront and as you go, any additional work can be immediately tested. Implement a new feature for a client? Run your test suite, and you’ll know immediately what, if anything, broke, and where. If you save your testing until the end, the process starts over every time there is a change.

To round out the taxation metaphor, I’ll close by saying that I’d rather pay as I go, regarding testing, than max out my coding credit cards. I can’t afford to accumulate any technical debt.


Branching Out

No, this post isn’t a reference to git. Rather, I’ve been making an effort to step slightly outside of my comfort zone. I’m making an effort to get more involved with the Ruby and software development communities, both locally and remotely/online. I’ve found that engaging with others is a great way to get a unique perspective on what it’s like to enter and work in the industry, especially from someone with more experience than you.

I attended both Project Night and the monthly Meeting held by the Boston Ruby Group this month, each for the second time. Boston has a great Ruby community, and there were a lot of familiar faces. The night began with a talk by Paul Dix on InfluxDB, a database for recording “metrics, events, and performing analytics.” I’m still fairly new to working with databases, so some of the topics were a little over my head. The project does seem to be coming along nicely, and I can definitely see the potential in it.

Next up was Wyatt Greene with his talk, “(Babies vs. Zombies)[http://techiferous.com/slides/zombies/]” (links to presentation slides). In case the title of the talk wasn’t clear, it covered how our brains work, and how abstracting code is an method to reduce “high cognitive load”. It was helpful as a beginner, since myself and others are trying to write clear, readable code. He gave a great example of two codebases that functioned identically, yet one was so unclear that nobody could determine it’s output by reading it.

After the talks, we were able to chat with Wyatt and get some good insight on his experience working both as a software developer and in education. He was very friendly and welcoming to those new to programming and interested in entering the industry.

The next night I attended a talk hosted by Automated Testing Boston called “Scaling Your Automated Tests Effectively”. Stephen Vance was the speaker. The group is fairly new, so the crowd was smaller, but we were able to chat with people from a variety of companies and backgrounds (they also had one of my favorite New England Beers, which was a nice bonus). This talk mentioned the importance of decoupling your applications, and warned of the dangers of the “big ball of mud”. Wyatt’s talk from the night before also brought up this concept, which really drove home the point.

Some weeks earlier, I had filled out a survey from GitHub about my background and usage of the site. I was contacted by email a week or so after, and asked to participate in an “Octostudy”, which is basically a chat with a couple people at GitHub. I spoke with user experience researcher and developer form the team.

This was a fun, relaxed conversation about when and why I started using GitHub. Thinking back, I signed up when I was thinking about trying to learn software development, and figured I’d have to sign up eventually, since just about every developer uses the site. Initially, I mainly used the site to star various repositories that I thought were cool or that I might want to refer back to later. I still use these feature often, but am now sharing more of my own code and collaborating with others.

I described my usage of secret gists for quick sharing of small programs or code snippets, as well as the feature to follow other developers to keep an eye on what they’re working on. They were also amused by a repo I had starred called “Cocktails for Programmers.”

Hopefully my feedback will be helpful to the team, as it will benefit me in the long run as a user of the site. I even learned they had checked out my blog (hosted on GitHub Pages, of course)!

All in all, it was great to put myself out there and interact with more people in the community. It helped to cement my descision that this is the right path for me, and gave me the confidence to continue working at it. I hope to continue to meet others working in the field, and eventually help others like myself to enter it.

For the moment though, it’s back to coding.


The TDD Way

At Launch Academy, we are exposed to and taught best practices for software development. One of those best practices is that of test-driven development, or TDD. As the name implies, it is a method of programming where your tests guide your decisions.

The idea is to reduce the feedback loop on your code. It’s an iterative process, consisting of writing a test, writing code, making that test pass, and then refactoring the code. Based on any errors you receive when running the code, you’ll be able to determine what the next required step is. It helps you figure out what you want to do, and then implementing the minimum amount of code needed to make that happen.

I find this style of programming very satisfying, as you will see visual indicators showing progress you have made. It’s almost like seeing checkpoints or objectives in a video game, which you must pass in order to advance to the next level.

Additionally, I find that it helps me write cleaner, leaner code. When writing a test, it forces you to think of how that part of your program will function. This gives you a clear direction of what code you will need to write next.

Prior to committing to learning software development, I worked in software quality assurance (QA) writing and executing tests. I helped to maintain and create new test cases for various features of the company’s web application. This experience proved to be helpful when writing tests, as I was used to coming up with various edge cases and trying to “break” other people’s code.

I loved catching bugs that slipped by while in QA, and now have the challenge of identifying potential potential bugs as a program is being written. Though it requires a slightly different way of writing code, which results in more upfront time, the potential for saving time overall makes it very worth it. I’ve seen many times where bugs have been caught before shipping, but then the source of the bug had to be determined, which can sometimes be the most challenging part of the process.

Writing code procedurally, focusing on one test at a time, definitely seems like the most efficient way to produce “bullet-proof” code. I’m on board with the TDD way.


Breaking It Down

Now that I’m really immersed in Ruby programming, the problems we are trying to solve are becoming more complex. This is exciting, as the programs have increased functionality, and aren’t just “one-trick ponies” that simply accept text and spit it back out to the user. We are writing code and starting to see the real-world applications it could be applied to.

With the increase in function comes an increase in the difficulty in building such programs, as one may expect. It’s easy to see the acceptance criteria for a program and get overwhelmed at how many features you need to pack into one program.

I’ve been learning that the best way to approach a problem is to break it down into smaller pieces. This allows one to work on each criteria, one at a time. This technique naturally flows into the idea of test-driven development, except without the use of automated tests. Doing so allows one to focus on one task at a time, treating them like checkpoints along the way.

This method was particularly helpful for me during the creation of a cashier program, which accepts orders and writes out transactions to a file, also reading back in this data for analysis about sales.

Focusing on one fuction at a time also allows me to concentrate more on that section of code, since I’m not worrying about the program as a whole. I can then write cleaner code that results in fewer RuboCop infractions.

After completing a feature, I can then commit to git, and move on to the next section. This serves as a good way to measure progress as well, as you can easily see what is and is not implemented.

Breaking down a problem also helps when planning out how you will structure your program, before you start coding. Writing a program is almost like putting together a puzzle, except that you must also create each piece of the puzzle before assembling it.


SpotCheck

The “breakable toy” at Launch Academy is a project worked on throughout the duration of the course, used as a tool to learn web development across the stack. While we are learning to program, we’re encouraged to try new ideas and techniques, most likely breaking the application during the process (which we can then roll-back to a working state with git, of course).

Coming from a video background, I wanted to choose an area that I was familiar with, that I would be motivated to work on during and after the cohort ends. Especially, I wanted to create something that I would personally use and get value out of.

Typical Process

In a post-production environment, countless revisions are made to works in progress, as clients request changes to a project, and editors make said changes and post for approval. Rinse and repeat until the client is happy, and the video, or “spot”, as they say in the business, is approved.

In my experience, the review process mainly consisted of several emails being sent back and forth between parties, often while “replying all” to ensure everyone was able to take a look. To see what changes were requested, an editor would have to dig through various email chains, trying to find the edits that were necessary to make. This process becomes more complicated as more versions are posted, and more people are weighing in.

Enter SpotCheck

To make this cycle more efficient, I decided to focus my efforts on SpotCheck. In my early planning stages, key features include showing a project status at a glance (“Approved”, “Needs Changes”, “Needs Review”), commenting on each video, and allowing specific “projects” to be viewed only by certain individuals. The goal is to have a simple interface to check which projects need work, and to quickly identify what that work is. This keeps all information in one central location, rather than scattered about in various emails.

video page wireframe

Above is a rough mockup of what a video page may look like, created using Balsamiq. I’ve created several user stories and acceptance criteria, and am prepared to pare down the feature list in order to complete a project that does one or two things well.

I anticipate being challenged by design decisions, as I am looking to create a straightforward and simple workflow. Other sites aim to solve simialar problems, and I hope to differentiate enough from them without delving into feature creep territory.

All in all, I hope to use my past experiences to build something that I would be happy to use. If others also get value out of it, that would be even better.


A New Way of Thinking

After finishing up the first week at Launch Academy, I find that I am starting to “think like a programmer”. A lot of this is a result of the various ways that my familiarity and confidence has been built up regarding different aspects of software development.

Command Line Comfortability

I’d always heard that the command line was a powerful tool, but never really knew where to get started with using it. Trying out a few commands, I never really saw the benefit over using a graphical file navigation tool.

After a week of forcing myself to use the command line, I am getting used to the speed and power it can bring. Creating and running files using the CLI (command line interface) feels so natural and intuitive.

On a related note, I’m finding error messages much less cryptic, and actually using them to track down bugs based on the location of the problem and the error type. It’s no fun runing into errors, but the faster you can identify and resolve them, the better.

Pairing Up

Pair programming was a new concept to me going in, but I’m starting to see the benefits. “Two heads are better than one,” as the old saying goes. It may seem counter-intuitive at first, but it allows one person to focus on the coding, while the other looks at the “big picture”.

I’ve also found it very beneficial to talk with others after completing a program to see how we approached it differently. I’ve found walking someone else through my code helps me understand what I did, and can point out areas where I don’t have a full grasp of why something works how it does.

Additionally, it’s helpful to have others available for a quick quesiton I’m making an effort to take advantage of having a large pool of individuals, all sharing a common goal.

Known Unknowns

There are known knowns; there are things we know that we know. There are known unknowns; that is to say, there are things that we now know we don’t know. But there are also unknown unknowns – there are things we do not know we don’t know.

The above quote from Donald Rumsfeld, while convoluted, calls attention to the idea of “known unknowns”. While it was heavily mocked, I think it highlights the importance of being self-aware in your knowledge.

In the past I’ve had trouble accepting that I didn’t understand something right away. I may get hung up on a small detail, which distracts me from moving on, or I could find myself trying to learn all aspects of a new topic and becoming overwhelmed.

With programming, there are often examples you’ll see code that performs a certain function, but not understand every piece of it. This is especially true when you’re just starting out and haven’t yet learned the necessarily foundational information to build upon.

For example, this past week I created my first Ruby on Rails app through the use of scaffolding (for demonstrative purposes). While not pratical for most real-world applications, it was helpful to see and interact with the structure of a typical Rails project. While I only worked with a few of the many files, it was helpful to give me a basic grounding, and served to provide me with a goal of learning to build a project without using generated code.

I’m accepting that I won’t understand everything right away; and that is okay. I think it is important to identify concepts that you don’t understand, and evaluate whether it is something you should learn immediately, or that it is something you should take note of and make a goal to teach yourself in the future.

Being honest with yourself allows you to take control of your education and determine the best path for you to take next.


Launch Academy or: How I Learned to Stop Worrying and Become a Web Developer

Growing up, I had always been fascinated by what could be accomplished with programming. I would play around with video game cheat cartridges or WYSIWYG web site builders, poking around the (poorly-generated) code. At the time, I just thought it was cool to try to do things that the software wasn’t necessarily designed to do.

Even without knowing how to achieve it, I eagerly wanted to make the transition from “it would be cool if this product did this” to “I am going to make this product do this.” I wanted to be the person that could build the functionality I had in mind, and not just wish for something better.

Over the years, I made some attempts at going down the coding path. While in school, I took some computer science courses where we learned and used Java. While I enjoyed solving problems and seeing my programs compile and run, I was intimidated as certain aspects of learning the language became more difficult. I became discouraged when I didn’t seem to grasp concepts as quickly as other classmates. One scare came with my first file I/O program, where a bug lead to my program eating up all of my free hard drive space.

A number of factors contributed to me not fully pursuing computer science, but I think a large one was the fear of failing. I didn’t fully commit myself, and used the first signs of struggling as an excuse to convince myself that programming was not for me.

Since then, the idea of being a programmer has not left my mind. I was considering my options, and decided I would teach myself to code, mostly using online sites and resources. During this process, I learned about the (fairly new) concept of “coding bootcamps”. Basically, they are an intensive course over a certain number of weeks that will teach you the skills needed to become a software developer.

The bootcamp model appealed to me especially because it would force me to fully commit to the goal of learning to program, and would also provide me with the support of like-minded students for when things get tough. Both of these benefits should help to break down the barriers I’ve faced in the past.

My ultimate decision lead me to join Launch Academy, which I’ll be attending soon in order to take the next step toward becoming a web developer. I’m fully-committed, and ready to face any challenges along the way.