Here are five articles I really liked reading as a junior developer. I’ve learned the most by doing things at work, but these articles filled in some gaps for me and helped me build a better, more confident mental model for being an “effective engineer”.

1. The Thirty Minute Rule

When it comes to coding (or anything related to it) there’s a rule I believe in with all my heart . . . if anyone gets stuck on something for more than 30 minutes, they should ask for help.

When I get stuck on a problem, it’s sometimes hard to strike a balance between helping myself and getting help from others. The thirty minute rule gives me a great heuristic for striking this balance.

When I started my first job, I often ran into blockers and struggled on my own for too long. Following the thirty minute rule helped me work more efficiently, though I’m still learning to apply it (sometimes it becomes the “45-60 minute rule”). And to an extent, this advice is helping me tackle my imposter syndrome and fear of looking dumb in front of other engineers.

2. How to ask good questions

A lot of people really like answering questions! I think it’s important to think of good questions as an awesome thing that you can do to add to the conversation, not just “ask good questions so that people are only a little annoyed instead of VERY annoyed”.

I found this article about a month into my first job, and I now apply its learnings daily. As the author points out, asking good questions isn’t just about “engineer etiquette”, but also turning my problems into an opportunity for mutual learning. I’ve had to ask many questions since I started working and this friendly, engaging article helped me make that a wholly positive experience.

3. Kickstarter Engineering Ladder

As a junior, I’ve often wondered what constitutes a “good engineer”. I’ve had 1-to-1 meetings with my boss to track my growth and get feedback, and this has been by far my best point of reference. But, Kickstarter’s engineering ladder is a great supplement to that, as it helps me identify other areas for improvement and provides another perspective on the fuzzy definition of a “good engineer”.

4. On Being A Senior Engineer

I expect a “senior” engineer to be a mature engineer.

According to the author, a senior engineer is not only technically savvy, experienced, and pragmatic, but is also a leader who demonstrates values such as humility and empathy. For the most part, the seniors at my company practice the habits mentioned in the article, and I think this has a big positive impact on the engineering org.

The way this article describes senior engineers provided me some direction for my future career path - not just in terms of skills, but in terms of the kind of person I want to be at work.

5. Model, Behaviour, Code: a three step process for designing software

Design is crucial to good software development, but many people lack a process for doing it.

This article is a great high-level guide for laying the foundations for a new software project. When I do my own personal projects, I often get overwhelmed by all the things that need to be done. By following this guide, I can trust that I’m not creating loads of tech debt as I work.

(And there’s another awesome resource that complements this one - The Twelve-Factor App. This website shares and explains opinionated best-practices for building, deploying, and maintaining a web app. I can see myself referencing it frequently in the future when I get stuck designing a project – I wish I had read it sooner.)