Thoughts after a year of programming

It's now been well over a year since I started coding and getting paid for it. And what a whirlwind it's been! Yet, as the year went by, I kept thinking that my experience rarely looked or sounded like anything I'd read in people's accounts of their programming experience. So I started reviewing my diary entries to see what's changed and what might be worthwhile to share more broadly. This post is a form of self-reflection rather than any attempt at dictating solutions. The biggest lessons you learn in software development (and arguably life) are that for many questions, the answer is "it depends" or "you do you." Many opinions depend on circumstances, and there's no one-size-fits-all approach for code, life, or the balance between the two. ## What I've been doing My first role consisted of building Atlassian Connect Cloud apps. Or, in the tongue-in-cheek words of our founder, to make Jira worse. Although I had been a Jira user before becoming a developer, I had no clue how vibrant the Atlassian app developer ecosystem is. Hundreds of companies worldwide build oftentimes incredibly complex apps that extend the functionalities of existing Atlassian products and contribute to Atlassian's success and reputation worldwide. The first three months consisted of a gentle onboarding gradient, after which things got real, fast. I learned how to make and launch a simple app (which users pay for, moved on to fixing bugs on larger ones, and eventually transitioned to client projects that have wound down as I write this. It took a year to graduate to ownership of a more complex app in which I'm encouraged to make decisions about the architecture and its evolution. Looking back on it, it was an exciting time, and in many ways just what I needed to grow. I was the third permanent developer hire, and I'll be forever grateful to the team for taking a chance on me. The whole experience turned me into an 'everything developer' rather than just 'frontend developer, something I didn't want to limit myself to early on. ## What I learned Too many things build up in a year, but these are the things I think about the most: ### It's not only OK to take your time, it's recommended The thing no one told me about code, coming from product management, is that it's OK to take your time when working on a problem. You can spend hours thinking about how to solve a problem. And, sometimes, it's not just OK, but it's encouraged. I came at programming from a world where managers expected "output" (docs, specs, meetings, decisions) almost every hour, and performance depended heavily on this factor. So it was a revelation that I didn't have to rush things out the door, and I could spend a good amount of time with a problem. I leaned into the deep work philosophy in my own way, and have been able to solve increasingly difficult challenges this way. When you take your time with a ticket, the whole point is to hone your skills to: * form a mental map of the system you're working on and useful working analogies (e.g., "This module imports this library, which seems to help with authentication," even if you don't know how authentication works at that moment in time - more on that later); * manage your emotions as they relate to code and frustrations, while developing advanced problem-solving skills; * get better at things like estimating the complexity of future tasks if your team expects such estimates in the context of sprints. There's a lot to learn and process when you're new to code and a codebase. If I had any advice, it would be this: if anyone disputes that it's OK to take your time as a junior developer, that would be a red flag. ### Learn to explain things with your own words At some point, you'll either have to walk someone through your code (e.g., in a sprint demo) or face an open-ended interview question like, "Explain what happens when you open a file in node." If you work with clients, they might call on you to explain your code and decisions to people with varying technological expertise and interest, often multiple times. Knowing how to explain things in your own words is an invaluable skill. Halfway through the year, I realized that the best way to consolidate my knowledge was to engage with it on my own terms to retain it better. For me, that meant writing; writing helps me think, so I started to write to understand. At first I wrote to get into the habit of it, and later started to structure it more. I ended up writing three things: * A private devlog, where I write about anything that challenges me. The entries have a simple structure covering what I know, my approach to solve the issue, and a reflection. It's deliberately simple, but it's a flow that works for me, with the reflection often the most valuable part; * A private 'wiki'. Some people call it 'personal knowledge system', but for me it's just a Notion space with some templates and structure built in Because I learned to code by myself, it would often take dozens of articles or videos to piece together a concept or distinguish facts from opinions. For each concept, I explain things in my own words, asking common-sense, deliberately constraining questions, like "What is this, and why would anyone care?" or "What is this good at/bad at?". As my knowledge and experience deepens, I often go back to tweak the explanations and nuances; * This site, for sharing any insights or unique experiences now and then. To some, this might look overkill or impossible. But a) I didn't start all at once, and b) I take my time, as mentioned above. Now it just feels natural, and that's the point. Whatever method you choose, if you can find a way to explain things using your own words, you'll become a more valuable and visible team member. Bonus: you'll also hone your critical thinking skills, which will serve you well as you grow. ### Be comfortable charting your path In an industry that can feel trend- and majority-opinion-driven, charting your path can feel like a radical act. But, ultimately, people hire you for your expertise, which you can only develop through direct experience. Early on, I realized many of the things developers tend to talk about online amount of noise. It may help that I came to programming in my 30s, and don't care for peer pressure or fashions. The IDE or popular framework of the day are trends, or things people experiment with on side projects, rather in their day-to-day job. While it's nice to be aware of trends, the only certainty is that they come and go. When it comes to actual work, many people can't talk about what, and how they do their jobs due to non-disclosure agreements, sometimes applicable long after leaving a position. That leaves little good information they can share in public. What's left to talk about (opinions, projects, etc.) can give new developers a distorted or narrow view of the programming landscape. The only questions that became important to me, that I try to ask myself regularly, are: * What makes time fly at work? What are my strengths? * What do I want or need for my next stage of growth? * What's standing in my way? And what could I be doing differently? In my chats with friends and peers, I realized these are not always obvious to new developers, so I might follow them up with more details. But armed with those answers and the knowledge gained from honest reflection, it's easier to find mentors who appreciate the effort that goes towards personal development. It can be scary to feel out of step with what others are doing, but in a world where you can do anything, do what makes the most sense for you.