2021.06.22
For today’s blog post, I’m taking a little break from API testing to convert a live presentation I once gave into written form. If you’re not a developer, the content about version control, or git, won’t be relevant, but you can still follow along without those bits.
Having a long career in technology will almost certainly mean continuing education of some sort. To me, the never-ending supply of things to learn is one of the things I love about working in tech. What self-directed learning looks like is different for everyone. Without the structure of formal education, for most of us, it’s a hodge-podge of video tutorials, books, conferences, and experimentation; often unfinished and undocumented. Obviously this is easier if you have a formal education partner designing your curriculum, evaluating your work, and scheduling your time, but most of us can’t stay in school forever.
The best approach I have come up with for managing my own development as a developer, is to manage it like an Agile project. You don’t have to be a Project Manager to do this, I’m certainly not a PM, but it does help to be familiar with the concepts and tools.
Pro-tip: Having a study-buddy helps a ton, so be sure to talk to your peers about their own professional development and pair up if you can.
What You Should Already Know
- Basic concepts of Agile project management. As the Product Owner, Project Manager, and the actual Product, you can define your Project with as much, or as little, detail as you need to in order to meet your professional development goals.
- If you are, or aspire to be, a developer, the basics of version control with a tool like git.
What You Should Have
- Some specific goals for your own development; long-term, short-term, or some of both. An example goal that’s too general: I want to be a rockstar developer. Better: I want learn how to write an API in TypeScript.
- Access to a Project Management tool like Trello, Jira, YouTrack, or even your own favorite to-do list app. There are many choices. Use what fits your own needs. I’m going to use Jira because it is what I’m most familiar with.
- Access to some training materials. For the purposes of this blog post, I’m going to use Treehouse. I have a soft spot in my heart for Treehouse that dates back to their early days when they were free-to-me due to their participation in Code Oregon. Also, the Treehouse materials are organized in a way that makes breaking things up into manageable Jira tickets really nice.
- Access to a remote git repository to show your work.
- An appointment calendar of some sort.
Let’s Begin
Given my goal of wanting to earn a good living writing code for as long as I can, my professional development is going to be focused on, well, coding courses. But that’s too general a goal. Since I don’t have a formal education in Computer Science, I often have FOMO when tech talk turns to algorithms. I didn’t use them at all in my many years of website development with HTML, CSS, JavaScript, PHP, and MySQL. Now that I’m about 5 years into automated QA testing, and using Python and Postman more than PHP, I’m intrigued by Treehouse’s Introduction to Computer Science Track. That Treehouse Track is going to be my first Epic in my Jira project.
Speaking of Jira, I’m going to start with a Team-managed SCRUM project with essential features and name it “Computer Science.” Once I have an empty project in Jira, I can add tickets to it. I’m going to create an Epic for the major topic I want to study, and then create Stories and Tasks for the Epic that map to divisions in the course work that are small enough for me to move tickets across the board. It is so satisfying to cross off items from a to-do list, or move tickets into the “Done” lane on a scrum board. This is how I’m doing it. You do you.
The first big item in this Treehouse Track is a Workshop with six videos. This is a risk for me to get bogged down in the PM side of my project at the expense of the course I’ve chosen. The Workshop has six videos in it and I could create a Jira ticket for each one; however, each video is shorter than five minutes at normal speed. I could spend more time on ticket management than it takes to watch the videos. Becoming a Jira Subject Matter Expert is not the point for me, so I’m only giving the whole Workshop one Story ticket in the Intro to Computer Science Epic.
The next big item in this Treehouse Track is a Course called Introduction to Algorithms with more than two hours of content. The Course is further divided into Chapters with each Chapter having multiple short videos. To me, this sounds like a better case for one Story ticket for the Course, and a Task ticket for each Chapter.
By now you get the idea. After creating the tickets to match the course, I add them to various sprints and estimate points along the way. While it is true that I’m probably the only one who will ever see this project, I have to remind myself to be realistic if I estimate points and plan Sprints. Estimating points and adding tickets to Sprints may seem like a bit too much Project Management again, but I do better with clearly defined short-term goals and deadlines that come from having tickets in Sprints. That’s enough to be going on with for Jira.
I could carry on like this indefinitely. I could create another Epic for a site I recently heard about called LeetCode. They have an Intro to Algorithms series too. Or I could find something on LinkedIn Learning, or YouTube, or HumbleBundle. Alas, I’m never going to live long enough to learn everything I want to learn because we keep making new things to learn. So the other trick is to avoid being distracted by every shiny new thing that comes along. I’ve been in web development for over twenty years and never legitimately learned Angular, a JavaScript framework that was the React of the day some years back. There’s not a lot of call for Angular devs these days, so I’m glad I didn’t devote a lot of time to it. By staying focused on the fundamentals, I can be confident that I’ll pickup the shiny new things if I ever need to use them for work. For other people, learning each shiny new thing that comes along is probably a fantastic way to stay motivated.
Show Your Work
Treehouse has some nifty interactive tools for working alongside their tutorials, but I rarely use them. I use my own IDE and commit my work to a git repo just like I do in my day job. If you don’t have an IDE, by all means use the tools Treehouse provides. I also try to take what’s in a tutorial and extend it, by adding functionality, or change it some way to be confident I understand the concepts.
Working locally with git allows me to go back and review what I’ve learned. If you’re new to your tech career, or spend your day job exclusively in private repos, showing your personal development work in your own remote repos also gives you code examples you can use to demonstrate your skills to potential employers. I’ve even been known to have different git accounts with different logins on my laptop to simulate what it is like to work on a team, with the potential for merge conflicts and all.
Professionals Show Up
All this planning will be for naught, if I don’t make the time to do the work. I am not a time manager by nature. Take away all my electronic tools and I’ll be doomed(?) to spend my days reading, playing fetch with my doggo, and staring at the ocean. If you’re like me, don’t think you’ll just magically find the time to do this extra work. It won’t happen. If I don’t carve out the time, and set appointments for myself in the calendar with reminders and all, it won’t happen. The built-in schedule is another thing I miss about formal education. The good news is, for me at least, I’ve found that by setting aside even 15 minute blocks of time, once I start the work, it gets fun and I often spend more than 15 minutes on it. Just be realistic about how this fits in with your life. Rest matters too. It’s not just for APIs.
Thanks for coming to my TEDTalk. [It was never a TEDTalk.] Stay tuned for the next post on… something technical.