Hack your Workday, Part 3

Ok, so in part 1 we learned all about goals and the importance of goal setting. Then in part 2 we put action steps to those goals to accomplish them and found some friends/colleagues/peers/mentors who could help hold us accountable. Now, let’s accomplish those goals within the confines of our workdays!

First, think about your day to day tasks. If you’re already a professional developer, you likely work on stories (or cards or tickets, depending on what project management tool your team uses). Keep a close eye on which stories relate to your learning goals. As much as you can try to accomplish your goals while accomplishing your work. If you can, the best thing to do is pick up or assign yourself to the story most related to your learning goals/goals. For example, if you want to improve your JavaScript, pick up the story that you know has some simple JavaScript tasks (at first) and then as you learn more, pick up the stories that involve more complex JavaScript. At first you might only pick up a story that involves reading and making a small change, but then as you make strides to accomplishing your goal, you might pick up a story that forces you to write JavaScript from scratch or refactor more complex JavaScript. If you can’t pick up the story, pay attention to who does pick it up and ask if they would be willing to pair on it. You might not have control over which tasks you accomplish but if you can pair, even for a part of the story, you’ll be learning more about what you’re trying to accomplish. If your team pairs a lot, make sure to gradually drive more and more in order to ensure the lessons are sinking in. Finally, if you can’t pick up the story and you can’t pair on it, make sure to read the pull request closely once it’s up. Regardless of whether the PR is open or closed, you can read through what’s going on and ask questions on parts you don’t know much about or don’t understand. If you have a team that won’t support the questions you’re asking, then jot down methods, syntax, etc. that you want to understand better and look them up when you have a chance.

Second, think about which of your goals are slightly broader, for example, they might touch on more stories. Whereas for a goal related to JavaScript, you may need to really try to pick up JavaScript-related sotries, think about a goal related to testing. You could be learning about testing for every story you pick up and every task you accomplish. Start a story by looking at the tests… do they exist? What do you think of them? Compare them to the file they are testing. Think about why each method was tested and how it was tested. Really think through the foundation that’s there. If there aren’t any tests, great!! Look at a similar file (if oen exists) to see how tests were written there. If possible, test drive the story you’re writing. If your company doesn’t allow that, hopefully they at least allow you to add tests afterwards. And specifically call out your test files in your PR. Ask for feedback specifically on your specs and spec file. Depending on how your team is at giving feedback, try to ask questions you’re likely to get good answers to. You may need to come up with more concise, specific questions to get the feedback you need to learn more. You will likely be learning lots of different things in every task you complete, but I’ve found when I have limited time, I can’t absorb everything so I learn a bunch but I make sure I completely understand and pay a little more attention to the items related to the goals I’ve set.

Lastly, think about what additional resources you can use as time-fillers and try to have these queued up in tabs or bookmarks. You likely won’t be busy every second of every day. Often, if you’re stuck on a task and no one is free to assist, or you’re waiting for code review, etc. you can often find yourself with 30 minutes or little bits of time here and there to learn. Find the folks that talk about you’re learning goals on confreaks, figure out some good blogs to check out or blog posts to read when you have time. I honestly don’t recommend books because if you’re trying to learn during work and just have bits and pieces of time here and there I find it difficult to follow and keep momentum going with a book, but if it works for you then have a book handy as well! Find some not-super-time-consuming code exercises (like Project Euler or old code challenges from technical interviews) that you can use to practive. Discover a podcast or 2 that you can listen to when you take a walk or are driving somewhere and note the episodes that relate to what you’re trying to be more proficient at.

In summary, you can incorporate all this learning and complete your goals within the confines of your workday if you stay focused and creative.

Read Part 1, Part 2, and Part 4

In Part 4, you’ll learn how to assess if you’re achieving the goals you’ve set and how to make time, without making time, to figure out what you’ve accomplished and naturally determine what your next goals may include.

comments powered by Disqus