A Day in the Life: Jack Ratner, Codecademy Software Engineer

This month, we’re featuring Jack– a software engineer, engineering manager, and long-time Codecadem-ian.

Meet Jack! :dizzy:

Tell us a little about yourself.

I’m Jack. I work as a software engineer at Codecademy. In my 3.5 years here, I’ve built a variety of features and worked extensively on our learning content management and creation tools. I’ve also spent a year as an engineering manager here as well. Outside of work I always have a coding project I’m tinkering on. They never work perfectly, but I’ve learned so much with each one I took on. I also have volunteered helping high school students learn web programming and loved it.

How did you end up working for Codecademy?

A friend working at Codecademy at the time told me about a software engineer opening here. I was the only engineer at a tiny startup at the time and was really excited to work on an engineering team with more than a couple people (I think we were around 9 people when I started, now we’re at ~80) and work on a product that impacted a large number of people.

Did you always want to be a Software Engineer?

Absolutely not! I went to a liberal arts school where I wanted to study Physics or Philosophy. I took an intro to programming class in Java there and didn’t look back. I liked my course work well enough, but it was working on side projects with my peers that made me excited to pursue a coding-related career.

What are the best aspects of working as a Software Engineer?

Hands down, problem solving is my number 1 reason for loving my job. There is nothing like the satisfaction of having created a working software solution after receiving a vague request like “I want to be able to do X”. Other great things include the amount of learning involved (there are always new tools), compensation (the pay is great), and the ability to work across crafts (work gets so much more exciting when you can work with people with other skills, like product designers and data scientists, for example). Oh, and debugging. I love the reward of finding and explaining the root cause of a bug at the end of a long, tumultuous search.

What are the worst aspects of working as a Software Engineer?

Not knowing where to start: sometimes a request comes along for you to fix or build something and you’ll feel totally out of your depth. Having mentors you trust (or even your favorite rubber duck) to turn to in these situations is immensely helpful, they can help clarify your thinking in these most overwhelming moments. Another challenge can be personality management. Some software engineers tend to think they’re the smartest people in the room. This can lead to software engineers confidently claiming they have the right answer to something, even when they are wrong (though I actually doubt this is unique to software, this is probably the case with co-workers in every field). Sometimes you have to cut through the sh*t to make sure you and your teammates get to a solution you all will actually be happy with at the end, and aren’t just listening to the most confident person in the room.

If you could make one piece of fictional tech reality, what would it be?

Of course the show Black Mirror immediately came to mind. I’m actually a bit of a future-tech cynic and worry sometimes that I’m contributing to our mutually-assured-destruction via code. All that aside, I think it would be pretty cool if someone were to create some kind of system that could convert those trash cyclones in the Pacific into some form of renewable energy. Actually all cynicism aside, I think it would be really cool to be able to interact with a computer by thought: use my brain as an input rather than my fingertips.

Do you have any advice for the learners?

Yes! A few things.

Have a reason to learn to code that is within your control. For me, that reason is always some kind of project (I want to make a website that shows the music I’m currently listening to). Having a goal of getting a job as a programmer is fine and good, but you don’t control your hiring decision. Build that website or app and the skills you need to be employable will come along the way.

Be humble. After your write your first few programs, you might start to think everything that follows will be easy. This is a classic learning trap. You will soon hit the hardest thing you’ve had to do and the sudden rift between your expectations and harsh reality may lead you to give up. You have to come in to learning to code (learning anything, really) with the expectation that it will always be challenging. Maybe you will become a master at it someday, but the moment you start thinking of yourself as a master is the moment you close yourself off to learning. Be humble, you will not ever know it all, but you will create great things if you keep yourself open to learning more.

Work with other programmers, particularly of different skill levels. Join a meetup or workshop group, contribute to open source, or some kind of online community (Codecademy has one :slight_smile: ). So much of what I have learned has been from getting advice on what I’m working on from other programmers and, inversely, helping other programmers with their projects.

If you could make one brand new course what would it be?

On Codecademy? I would have us teach the most popular python web application frameworks: Django and Flask. My hunch is that they would be applicable to and wanted by a pretty wide audience of users. Now, what I would want people to learn is debugging. Debugging is so important to being successful as an engineer on a day-to-day basis, but I think it’s often an under-emphasized skill throughout the career journey as an engineer.

What does a typical day look like for you?

My typical day has varied a lot over the years. As an engineering manager, my time typically broke down between:

  • regular 1-1s with my teammates (how most managers + reports check-in in the tech industry), 25%
  • code review, 10%
  • project scoping + technical design meetings, 10%
  • strategy things (hiring, roadmapping, resource allocation), 15%
  • bug fixing and small project contributions, 30%
  • misc. other meetings and putting out fires, 10-120% depending on the day

Yes, I know those don’t add up to 100%. As a manager, you have to make tradeoffs with how your time is asked of you, and you never really have the time to do all the things you want or need done.

As a software engineer, my time breaks down differently:

  • code review, 20%
  • project scoping + technical design meetings, 5%
  • bug fixing, 10%
  • coding, 60%
  • misc. other meetings and putting out fires, 10-120% depending on the day

Yes, software engineers have to respond to issues, too :slight_smile:

2 Likes

:+1: x 100 for Django. It’s a brilliant framework for beginners. :smiley:

2 Likes