Apprenticeship: From Clinical to Computer Science
26 October 2017

Apprenticeship: From Clinical to Computer Science


I’ve been a Gaslight apprentice for four months now, and it’s great! I could not have asked for a better introduction into this field than an apprenticeship. I’m a functional member of a team of seasoned developers, learning from them every day. Additionally, I work with a fellow apprentice with whom I can share victories or commiserate.

Before all this programming business, I was a clinical scientist at a Hospital in Nashville Tennessee for two years. Initially, I enjoyed the fast-pace of the work, but it became monotonous since the nature of the work is very procedural and standardized. During this time, I realized what I desired from professional endeavors: something not solely procedural nor standardized. I wanted something with room for error, differing approaches, and collaborative problem-solving.

I had recently heard about a Software boot camp in town and began some self-study to see if I could see myself going this direction. 
Not long after, I joined the Nashville Software School, a full-stack (client and server side) web development boot camp. This was an inspiring and formative experience. I learned the basics of a couple languages, how to work in small groups, git, Unix commands, and other developer tools. I also learned that software development is something that I dig, and a field in which I’d want to pursue a career. Though, the path to employment was indistinct. I didn’t feel like I was ready to fill a junior developer role at this point.

Software development has met my desire for nonlinear and collaborative problem-solving. An illustration of this nonlinearity is the test-driven development mantra: “red, green, refactor”. Meaning: write a failing test, write code to make that test pass, then improve the code while not altering functionality. This is neat to me. Five different people can write code to make a test case pass, and if the problem is complex enough, there will be different approaches. Afterwards, you can get with the other four people and learn from their techniques. Or better yet, you can pair program and bounce ideas around while solving the problem!

There’s a cliche of the solitary coder; a lone wolf, face illuminated by a screen’s glow, solving a complex problem all by their self. In my experience and in talking to other professional developers, collaboration is the rule of which there are few exceptions. Large, morphing codebases make entire-system expertise rare and unsustainable, so collaboration and open exchange of knowledge are very important for everyone getting their work done effectively. Large tasks may require more than one pair working in closely related files, so communication is vital to not duplicating work or causing conflicts when merging into version control.

I’m now going to offer some unsolicited information and advice to those interested in an apprenticeship:

  • Ask questions.

Do yourself a favor and ask questions often. Also, do the recipient a favor and offer them pointed and concise questions.

  • Keep a notebook and write things down you do not understand.

Later on, you can try to understand these points, or come up with questions to ask your teammates.

  • Embrace pair programming.

This will probably be a huge shift in the workflow you are used to, but I’ve grown to really like it. If you’re working with someone who is on a comparable skill level, there’s a nice, open exchange of ideas and energy that is motivating. If you’re working with someone at a higher skill level, there is the opportunity to learn through example.

  • Fail fast, but small.

This was advice given to me by a coworker. There is a lot of trial and error in this field, so failing is inevitable. But, you can mitigate some pain if you try to make your fails as small as possible.

  • On feeling discouraged:

Find the roots of the feeling and be swift in your remedial efforts. It is important to have an honest self-dialogue, and not ignore how you feel. Do what is necessary to get yourself back in an optimal mindset for learning.

  • Don’t compare yourself to others.

This might be difficult since you’re but an egg in this field, but I think it is important to emphasize. Instead of dwelling on these toxic thoughts, ask yourself what you could learn from them.

Heads up! This article may make reference to the Gaslight team—that's still us! We go by Launch Scout now, this article was just written before we re-introduced ourselves. Find out more here.

Related Posts

Want to learn more about the work we do?

Explore our work

Ready to start your software journey with us?

Contact Us