Setting goals for my first year as a software engineer

I asked the Internet for advice, and the Twitter community delivered

I started teaching myself to code a few years ago, and I was lucky: between Codecademy, Free Code Camp, Women Who Code, and Fullstack Academy, I had an amazing support system.

Now, after a few months on the job, I’m kind of unsure what my next goals should look like. I poured my heart and soul into getting here. Hooray! I’m a software engineer! But…what now?

I polled the Internet, and the Twitter community surprised me: hundreds of people sent responses.

It was all such good advice, I wanted to organize it for regular re-reading. So, according to our friends on Twitter, in order of how often each topic was mentioned, here are some goals for year one:

Find a Mentor

Find someone you respect or someone who has a job that you would love. Get coffee. Reach out on Twitter. It’s awkward. It’ll totally be worth it.

Ask Questions

(a.k.a. it’s o.k. not to know everything)

You’re not dumb. Your question is not dumb. Oh, you’re sure it’s a dumb question? Ask it anyways. Your team will (should) support you in learning. Figuring out what, how and when to ask is key. Sometimes working through something on my own is productive, but after a certain amount of time, outside input is worthwhile. Also, asking for more background information or “why” instead of “what” or “how” can be valuable! These thoughts really helped me out:

Write Tests

So many people on Twitter expressed regret at not having learned how to unit test or apply TDD earlier in their careers. I’ve spent the last few weeks writing tests for my team at Quartz and I can *attest* (…sorry) that it is the best way to familiarize yourself with a new code base. I love this sentiment about getting “into the guts of it:”

Get Better at Debugging

In general, Twitter seems to have a pretty unified front on this one: get better at debugging. *How* to get better at *which parts* of debugging is still kind of mystery to me, and I’m sure I have decades of research ahead. That being said, these thoughts were pretty helpful:

Read Unfamiliar Code

Another topic that came up again and again was code literacy. Reading unfamiliar code is hard — it’s a skill that we all need to develop through practice! Fortunately, there are lots of different ways to practice, whether it’s reviewing code or contributing to open source projects.

Become a Git Master

This one surprised me — I know the basics of Git, but I kind of viewed it as an unfortunate necessity, like…I don’t know…RegEx. So many people encouraged me to master Git, and the difference between rebasing and merging came up today at work, so I’m going to take these kind people’s advice and get on Git.

Write & Share What You Learn

So many people encouraged tracking learning in some way. Some people recommended a technical journal while others recommended jotting down learnings each sprint. Some people encouraged going to meetups and conferences, while others encouraged teaching to learn through mentorship programs. There are too many avenues to go down in this post, but my major takeaway was to stay active in the community. We are all in this together!

Go Deep, Not Wide

A lot of the advice shared boiled down to, “make sure you actually understand what you’re doing. LIKE REALLY THOUGH.” I think we are prone to a couple of things:

1. We want solutions as fast as possible
2. We want shiny, fancy, fun new things

This advice served as a “here be dragons” warning for me — I’m going to try to slow down and make sure I am focusing on knowing my stack, making sure that I understand it well enough to carry the learning over when it’s time to adopt something new.

Always Be Learning

(a.k.a. have fun!)

A lot of folks also warned against getting stuck in a rut. Staying flexible can be tough, but we’re also in a field that’s constantly evolving. Whether it means starting a personal project, taking a course, or going to a new conference, integrating constant learning into your career seems pretty key. It also keeps the work fun!

Time Management

A lot of people brought up time management and it’s something I’ve been thinking about a lot. Everyone has a different flow for their days and their sprints, but it seems pretty crucial to at least be aware of how you’re spending your time. Making conscious decisions to spend a certain amount of time on learning, growth, planing, researching and replicating a problem before diving into the code seems like a good starting point.

Stay Healthy & Beware of Burnout!

Wow, there were so many comments about health in this thread. Learning to say “no” and building healthy work boundaries was a major theme. Also, apparently getting enough food and sleep is a big problem for us brainiacs. Well, I guess I’m off to join a yoga class…

Don’t Put Up With A Shit Work Environment

This category of advice is sad, but unfortunately necessary. As a career changer, I feel like I’m lucky (?) and experienced enough to have learned this in previous roles. If you are stressed or unhappy, take some proactive steps:

1. Document everything. EVERYTHING. Avoid the “impromptu in-person meeting that no one else witnessed” nonsense at all costs.
2. Limit the damage — is the drama/stress/negativity really your problem? Can you remove yourself from that environment?
3. Don’t let someone gaslight you. Your feelings are valid, and you should not stay in a toxic workplace.

Run Your Own Race

Giant ego? Shut. It. Down. Imposter Syndrome? SHUT. IT. DOWN. We all struggle when we’re assessing our own abilities, and we share a lot of the same highs and lows. Learning how to take constructive criticism, maintain a positive attitude, and trust in my own abilities…well…check back with me in 30 years. I’ll probably still be working on it. In the meantime, I will take Steven Sinofsky’s advice and do what needs to be done. ❤

Conclusion

First of all, an ENORMOUS thank you to everyone who took the time to respond! This thread is chock full of timeless advice, and for me, 2019 will include:

1. Attending a conference (I have my eye on Write/Speak/Code or SRCCON)
2. Finishing a small personal project using a new library or language.
3. Blogging at least once a month about what I’m learning.

In any case, I think this tweet from Matthew Fazza is a good wrap-up. I don’t know where I’ll be in ten years, but I hope that I’m (still) doing the work I want to do.