Apprentices are a fundamental part of the cycle of knowledge that keeps a craft alive. A member of the older generation would take in a young student and teach them the ‘tricks of their trade’. Nowadays apprenticeships are thought of only being used by plumbers and technicians. I challenge this. For any skilled work, without this cycle, deep technical knowledge would take lifetimes to learn and we don’t have that kind of time. RIT recommends taking a year off to work on a co-op, internship, apprenticeship, whatever you call it, you’re going to be working ‘software’ for a year. I think this is one of the best things aspiring software engineers can do and I’d like to share some pitfalls and lessons learned from my year on co-op.

Starting

It’s said that the first 20 year block of your life moves slower than any other 20 year block. This happens for a few reasons. First, you haven’t been living for that long. So a year between the ages of 1 and 2 will feel like a lifetime, but 20 and 21 goes by in the blink of an eye. Second, once you start working, new experiences don’t happen as frequently. How many times can you get dumped for the first time or learn how to drive a car. The same can be said for the first few weeks of your apprenticeship. Everything is fresh and new, there’s so much to learn. You’re surrounded by people that know way more than you. It can be intimidating, but that’s ok! If you’re the smartest person in the room, you’re in the wrong room. It’ll feel like you’ll learn more in the first few weeks, than your entire college experience.You’ll definitely want to get into good habits: take a lot of notes and ask a lot of questions. You’re lucky if your company has an onboarding program. Having someone tell you all the stuff you don’t know is going to disseminate knowledge more efficiently than trying to figure out the unknown unknowns (what you don’t know you don’t know).

If you don’t have an onboarding teacher, the next best thing (and even if you do have an onboarding mentor, you should do this) is pair programming. Just do it. There are so many awesome things that pair programming leads to. Some of the obvious include learning problem solving skills, how to use tools, tricks of the trade. But there are some hidden bonuses of pair programming with teammates. You become friends with these people, you’re directly working with them, they see your progress, you see their help and friendship. When I first started, I didn’t necessarily have a specific pair, but I would take every opportunity to pair up with my teammates. Larry taught me how to go fast and see what was important, and Shaun taught me diligence and how to solve problems like a machine. When I started, I was using Sublime Text Editor because that’s what I used in school and it was easy to pick up. After seeing their work flow I picked up vim (the text editor I’m using to write this article in!). One of the biggest perks was being able to type without a mouse. This reduces times spent typing/moving the mouse and more time thinking about problems.

Work smarter, not harder

One of the easiest pitfalls to fall into when you first start is feeling like you need to be ‘busy’ or ‘productive’. For an apprenticeship, this is a fallacy. I’ve said this over and over, no one expects you to be a rockstar coming out of school. Heck, no one expects anymore from you than an open mind ready to solve problems and a positive attitude. I had worked one co-op before CoverMyMeds and I fell right into this trap. I felt I needed to be productive from Day 1 and kept trying to get work done without having a solid foundation. It never gets better if you work like this. You never learn the fundamentals of a language which makes your job easier. At CoverMyMeds, I spend about half of my day just learning, reading, practicing, listening, absorbing. ‘Knowledge builds up like compound interest’ - Warren Buffett. This is one of the truest things that I’ve seen in my time at CoverMyMeds. I invested a lot of time in myself at the start and it pays off. Knowledge allows me the time to continue investing in myself. Now I do more work in the 3 hours before lunch than I would in a whole day. It’s really f-ing cool.

Prioritizing your learning is definitely one of the best lessons to learn. I focus my time. I work for a web company, so I spend my time learning about our LARP (Linux, Apache, Rails, Postgres) stack. At first it may seem like just learning language specific knowledge is the most important thing. Understanding your language is going to make understanding frameworks so much easier. Learning metaprogramming definitely takes a lot of the magic out of rails, for example. And while it’s definitely important there are other facets to focus on. Domain Specific Knowledge is what helps you understand how your company works and operates. For the most part, this stuff comes naturally via osmosis, but it’s 100% one of the most important types of knowledge to make informed decisions. This knowledge specifically gives you a lot of business value. Framework and Library Specific Knowledge, no matter who you’re working for, it would take forever to start from scratch. Luckily, some masters have come along to make your job easier. For us Rails is a massive time saver. It may seem like a mountain to climb understanding all of the conventions to follow, but as I said earlier, it’s all just Ruby. Tool Specific Knowledge, this is definitely one that I didn’t think about, but the number of times that you need to go to the end of a line and beginning of a line in a given day is… a lot. Just learning about your text editor and shortcuts can pay off leaps and bounds in saving you time throughout the day. Take note of all the tools you use, and take the time to do the diligence of learning them. Personally, I use vim, iterm, zsh, and an assortment of gems everyday. Remember, a poor craftsman blames his tools. Along these lines, there are more abstract pieces of knowledge, I consider this Engineering Specific Knowledge, this encompasses things like how to elicit requirements, software architecture, and security. Finally, Technical Specific Knowledge this is where I encompass the rest of our stack. For example, postgres. You can get by without knowing sql, especially with the help of activerecord, but it’s like going back to square one when you have to do anything advanced or outside of that tool. Other examples include Redis and Linux. Remember, Software Engineering is an adventure in lifelong learning, no one expects you to know everything coming out of college. To be frank it’s hard to even pretend that you know everything.

Read between the lines

Sometimes the work you’re going to do is going to quite frankly, be boring and tedious. Updating libraries and filling out auditing forms can only be interesting for so long. It can be easy to just stick with what you know, those tasks become comfortable for you. This is another pitfall, sometimes you need to carry water for the master, but when the master thinks you’re ready for the next task, you should jump at the opportunity. These opportunities come in the form of emails that say, ‘Looking for new members of the application security guild’, or invitations like, ‘hey we’re going to a hackathon, would you like to be on the team?’ When you see an opportunity that might be hard, jump on it. Another pitfall that I’ve run into is saying ‘no’ to too many things, a lot of people don’t necessarily see the value in going out to trivia night with a coworker, but those relationships pay off in the long run. And if you take on a work assignment, and fail, that’s awesome! Think about all the things that you learned from that. Since high school, I’ve been a part of about 5 ‘startup’ ideas, and none of them took off, but every time I work with another group, I learn all the things not to do when starting out as well as when the road signs are there that tell you, “this isn’t going anywhere.”

Have Fun!

You too can watch lightning talks on a boat. ~ Cleveland Ruby Brigade Meetup at Lean Dog.

You know who enjoys going to work everyday? People that don’t feel like they’re going to work everyday. The relationships gained with your coworkers, and the satisfaction of work pays off emotionally and mentally. That being said, software engineering is our craft. It’s what we enjoy doing, but it shouldn’t be the only thing we enjoy doing. When I first came to Columbus, I wanted to progress my swimming hobby, so I joined a local Masters Swimming group and made a bunch of friends there, as well as impressed myself at how many times I could wake up before 5 am. Do your hobbies in public meetup.com is one of the best sites when you come to a new city. Go to as much as possible and cull the groups you enjoy from there. Quantity breeds quality. User groups like the Columbus Ruby Brigade are great tools for learning what other people are doing with your tools. Hack nights are another great way to get an outside perspective on any side project that you’re working on, as well as get feedback from others outside of your work circle.

Coming to a close

I’ll say that in the year and a half spent on co-op, I’ve learned more in the first 2 months of each block, than I had in the 3 years I had spent in school. Hopefully, this article will give a little more guidance than ‘go to work for 15 weeks’ I have faith your apprenticeship will set you up for future success in the field. I’ll leave with a final quote, “The people I’ve met and the places I’ve been, all make me the man I so proudly am”.