I just completed a three month long fellowship with Bang Equals development. This was my first opportunity after formal training to work in the development field. As such, I thought I would take time to reflect on the experience. In this contract, I learned about working in a production grade codebase, adding value, planning code, building customer experiences and gaining a better understanding of the life as a developer.

Working in Production

Working in a production codebase was probably the most powerful aspect of my fellowship. Working in your own projects vs. jumping into someone else’s established work delivering actual revenue are two different eco-systems. For starters, in production you are much more likely to have way more power than you anticipate. I learned the importance of good documentation when one of my shell commands inadvertently re-indexed an entire data collection. Fortunately, no data was lost, but both I and the lead developer instituted plans to update the documentation for future clarity.

Adding Value - Your Unique View

There were places in the code base that needed work. But like that dust ridden corner of the kitchen, you no longer notice it enough to pick it up (at-least until spring cleaning, of course). These long forgotten corners are where you can make the most impact as a new developer. I would suggest formally tracking what could be improved and how.

In my case, I used a markdown editor and uploaded screenshots with helpful bullets of suggested improvements. Using this tool, I tracked the removal of deprecated Rails methods no longer supported in our version. Also, I implemented a feature allowing control over the viewport (minimizing large data views) with a click of a button. The users loved it! Over the course of the contract, I worked with the lead developer to fix and update other areas. If I hadn’t made the initial note, these areas would have remained dusty and forgotten.

Working Through Problems Efficiently

Quite a few times times during the contract, I would work out a solution to a problem for a few hours only to have the work completely change during one five minute interaction with the lead developer. A good example of this was when working with our database, I developed a rather complex rake task to update some some models. I thought the solution needed to be very robust and future-leaning. After discussion, five small shell commands were all that was required.

The TLDR - work fast by working small (Agile). Come up with a quick idea and implementation plan first, and then present it to your team. Assuming you are still learning the codebase, they will have a better idea of what needs to change, if anything. At the end, you will have saved yourself time and frustration by keeping communication and future work open and iterative.

Less Is More

But less is less - right? Wrong. When it comes to visual design, I learned very quickly the customers viewport can clutter surprisingly fast. My best advice is to build the smallest thing, send it for review and then add to it later as needed (Agile). Specifically, when I first started, I would add colors, borders, and icons to my customer facing views. A good example, when adding a customer data privacy notice to a page, I added a nice border box and additional CSS styles to make the checkboxes appear different than the default. Some of this work was retained, but most was discarded in the end. It simply distracted the eye and wasn’t needed. Start small, build up.

The Dev Life

What is the ultimate value that you bring to the table as a developer? Previously, I always thought it was some magical technical ability. Sure, as Cal Newport mentions in his work, So Good they Can’t Ignore You, there is a an element of mastery needed in any chosen field. However, its seems to me, in addition to proficiency, a good developer brings a mix of insight, positivity, tenacity, and dedication. I will be forever grateful to the lead developer and what I gained from this first contract experience.