Before becoming a parent, I had oodles of time... of course I didn't realize this but it was true. When I was learning to code, I spent hours and hours and hours programming. In the zone? No problem, I'll just keep going. Want to catch up on a few conference videos over the weekend? Sounds great. Can't go to a conference but want to know what's covered? I'll just keep my eye on Twitter during the conference. I look at this freedom now and laugh... like a histerical I-have-so-little-free-time now that thinking about all that free time is funny. I've also felt more frustration at the community that I know and love. People the say get involved in open source, code every day, just do more on the weekends, etc. I found that when attending conferences or reading about ways to continue leveling up, the suggestions always seemed aimed at folks with a significant amount of free time.
I had my son when I was only 10 months into my first full-time developer position after doing a career transition and teaching myself to code. After having my kiddo, I needed to figure out how the heck I was going to keep up and continue learning. While having a child is what sucks all my time (in the most wonderful way possible), I also started to understand other folks. The people that have larger families, are taking care of older or sick relatives, ones that work multiple jobs... copious amounts of free time is NOT always an option. This series will provide some tips and tools to making the most of your work day because in this industry, we've all gotta be learning all the time.
Tip #1 is to create learning goals. You can't focus your desires unless you know what you want to learn. Think critically about these goals. They should be achievable within the timeframe you're setting for yourself, actionable, measureable, and concrete. This is SUPER hard to do in software development because you usually can't set as a goal to build a specific feature, for example, especially if you're looking at accomplishing these goals within the context of your work day. Remember, you also aren't always in charge of your destiny at a company. They could switch what project you're on, change your priorities, etc. so banking on a goal related to a specific feature is challenging. Make sure your goal is also a little flexible and will work no matter where you are. Not to mention the fact that creating measurable goals is challenging.
Make sure to develop goals within whatever timeframe you're determinig for yourself. My personal style is to write goals at the beginning of every year and revisit/revise them quarterly. I try to make most of my goals achievable within a quarter, but there will often be 1 or 2 of them that go a little longer than that.
Measurable goals are tough within software development because there are very few quantitiative measurements you can commit to. For example, you can't say how many lines of code you'll write or how many features or refactors you'll complete. When determining a goal, also think about how you might measure your progress and determine success. We'll talk about this a little more in a future post as well.
Don't write too many goals. I usually try to keep my list to around 5, some smaller and some bigger. Remember, you're confined to the work day and want to make sure you're getting all your work done so don't overcommit.
A great resource to read through is learning about SMART goals. These goals are specific, measurable, asignable, realistic, and time-related. You can read more about it here or by Googling "SMART goals". A lot of these posts provide some really helpful tips for making sure you can actually assess success or failure of a goal.
Okay, so here are some examples, without the additional action items which we'll cover in the next post:
- Learn more about APIs
- Ask at least 100 questions per week
- Write a useful script
- Increase my confidence level as a developer
- Understand the basics of relational data modeling and relational data
- Continue to improve in testing and learn more about testing concepts like stubbing, mocking, and message chains
- Give constructive feedback
Try writing a few yourself and see how it goes.
