Issue #8: Hack Your Day to Learn at Work
In a recent retrospective at work, a member of my team was lamenting the lack of time to watch courses or do training due to their workload. When you're strapped for time at work, how can you make time to keep learning?
Maybe we can borrow from the same ideas I laid out in a previous newsletter with how I make time in my personal life for stuff that matters to me:
Kamran Ayub
My "typical" workday
In that issue, my day had a few blobs of time we can just call "work" that spans from 8am-4pm-ish with a break for lunch:
As I've progressed in my career as a software engineer, my "typical workday" has definitely evolved.
The joy of being unknown
When I was starting out, nobody knew who I was and I couldn't answer any questions really, so nobody asked me anything. I basically had the fabled 6-7 hour workday nearly free of distraction to focus on work. Of course, I was still in Corporate America so there were some meetings with the team and such.
There was plenty of time to learn. In fact, since I had never worked in a professional capacity before doing programming, I'd say most of that time was spent learning.
The horrors of knowing things
As I got shit done, got promoted, people started to want my opinion and I also needed to respond to questions about products or features I built. I also knew more. I had learned more.
It wasn't long until my days became peppered with meetings and distractions.
Aside: Toilet Time
When meetings are scheduled 30 minutes apart, I am not sure what to call it but let's call it Toilet Time. This is time that gets flushed away down the toilet because you can't establish focus enough to get meaningful work done. Hell, it may even be literal toilet time because you have so many meetings you can't escape for a bio break. I've had those days.
With traditional office meetings, you had "travel time" between meetings even if they were back-to-back. Now with COVID-era Zoom meetings you have zero travel time. Luckily at Target we've implemented a loose policy that meetings have 5-10 minutes in-between them.
What is "learning time" anyway?
Is it time outside normal work? Taking a course? Watching a video? Doing some open source work? Whatever it means to you, I have a revelation.
No matter what your workday looks like any discretionary time you have can be transformed into learning time.
🤯 Right? Still not registering? Maybe this code snippet will help:
const discretionaryTime = [
{ type: 'sprint work', start: 8, end: 9 },
{ type: 'sprint work', start: 13, end: 15 }
];
const learningTime = discretionaryTime.map(timeBlock => ({
...timeBlock,
type: 'learning'
});"But Kamran," you exclaim, annoyed 😣, "I have product work to do during that time. I can't just watch a YouTube video!"
And to that, I chuckle and whisper in your ear that I have some hot tips to share I've picked up in my 11-year career to do just that.
Tip #1: Work on stuff you don't know
The number one way to make time to learn is to simply take on sprint or product work that involves some new tech or skill you want to learn. I was always eager to take on bleeding edge features or features I knew exercised some aspect of development I wanted to learn. We need a Visual Studio extension that uses COM+? I have no fricking idea how that shit works, I'll take it! And then I learned how to load WPF apps in Visual Studio instead of boring old Windows Forms. You see what I mean?
There's a reason why interns or new devs on the team's standup updates consist mostly of "I spent most of the day learning" because they're coming up to speed with things. Nobody bats an eye at that. It's expected when you're new. The secret is that this doesn't have to stop as you advance in your career. You just don't need to say it explicitly during standup because it's just naturally part of the work.
Keep picking things that may involve new tech and you'll be able to get sprint work done plus learn something in the process.
Tip #2: Find a new team (or job)
This one is less cynical than it sounds. It's similar to #1 but more drastic: if nothing on your team's plate is involving something new, maybe it's time to transfer!
At General Mills, every new hire actually was basically required to rotate every year up to 3 or 4 times. You can appeal this with your manager, it wasn't set in stone but here are the teams I rotated onto during my 7 year tenure there:
- Microsoft Center of Excellence team – Learned .NET, C#, CI/CD workflows, SQL, Visual Studio extension development
- Consumer Internet Sites team – Learned responsive design, CSS, working with PM & "business" folks, and frontend engineering
- Consumer Internet Platform team – Learned Elastic Search, building multi-tenant site infrastructure, Sitecore CMS, leading a scrum team, high-velocity sprint culture
- Web DevOps team – Learned about Site Reliability Engineering, Windows servers, Linux servers, Azure cloud, CI/CD architecture, Artifactory, Jenkins, F5 load balancers, TCP/IP networking
That's 4 teams plus there's even more smaller projects that involved tons of other stuff where I was constantly learning.
The fact is: if you want to learn something new maybe you need a change of environment.
When I joined Target, I had never worked full-time with React or Node.js – it was a total change of scenery and I've been learning tons ever since joining. React, GraphQL, Node.js, JavaScript, TypeScript, Docker, etc.
Tip #3: Use the shadows to your advantage
When I joined my first team at General Mills I was tasked with working on our internal "build and deploy" tool. It was a web-based site built with ASP.NET that was a pretty clearly "developer built" tool. General Mills didn't have enterprise UX, this was back in 2010.
It was clunky. There was no UX to speak of even.
So what did I do as the new person on the team? Well I fucking made it better, is what I did. And nobody told me to.
That meant in addition to the stories/tasks I took on during the sprint, I had so much time (remember: new kid) that I just worked on whatever I thought would improve the UX and developer experience.
This was a) aggravating to my agile scrum master but b) was incredible for my notoriety at work. Suddenly, devs were asking who was making all these great changes to make their lives easier! My manager on that team is still my all-time favorite manager because he was so supportive and never shut me down. The tool became easier to use and another thing happened: people started caring about UX and then coming to me to get tips on design. My title was not UX Engineer but I made UX a focus of my work and it helped me in my career to boot.
Like Garret sneaking around in the dark, sometimes the best things happen in the shadows. Invent work if you need to learn something new especially if it serves others. Hopefully, your manager is cool with it.
Tip #4: Carve out the time
At Target we actually have sanctioned time called 50 Days of Learning. This is an initiative our leadership supports where you may use basically 1 day a week for dedicated learning and no one should bat an eye. I've found our leaders support and model this behavior. What I've also observed is that product teams under deadlines tend not to use this sanctioned time.
I am going to suggest that sometimes you must do something a little rebellious and that is to push back and not work on product work 100% of your discretionary time. Not in 11 years of my career has anyone pushed back on me saying I used time to watch a conference video or spend time learning new technology. I have had pushy PMs/agile folks be a bit exasperated but guess what? Eat it. 🔥
Your career is yours to control, not theirs. And guess what? A lot of times, what you learn in a talk or in a new tech is almost always applicable to day-to-day work that improves some workflow, fixes an issue, or has some positive impact on the business.
Tip #5: Go to a conference
This is a great way to hit a bunch of checkmarks on your list (sans COVID):
- Get out of the office, away from distractions and (most) coworkers
- Have some fun and get on a plane
- Go somewhere to experience the city outside the conference
- Have totally dedicated time for focusing on learning
- Meet new people!
This depends on a lot of things like budgets and bosses and all that junk but if you can manage to attend conferences, you can get TONS of learning in you'll be exhausted by the end of it.
Some of my best career memories are going to MS Build with my friends/coworkers and meeting product teams at Microsoft.
Tip #6: Start a reading group
Maybe you can turn one of those Fixed Time blocks into an asset! I've had coworkers take on the initiative of starting a reading group. I remember going through the Working Effectively With Legacy Code book and it was awesome. It's a great way to get that sanctioned time even when you feel pressed since you have a group of other people to hold you accountable.
Tip #7: Give talks
This is still one of my go-tos. I don't think there was one major internal developer conference I missed at General Mills, I always tried to give a talk. What's great about this tip is that you can use work time to work on work talks. The word "work" appeared 3 times in that last sentence so it's gotta be good!
If you ever thought you needed to know a topic deeply before giving a talk, I am here to tell you that's a damn lie. Do you know how many talks I've given where I only tangentially knew the subject? A lot! The secret is that you learn the topic even better when you teach it to others. My approach is to sometimes give a talk internally and then if it seems worthy, take it public after learning more deeply.
There are many, many benefits to speaking, even if just internally:
- You are automatically seen as an expert
- You get to know a topic pretty deeply
- You learn public speaking skills (yes, it's a skill)
- You learn to articulate thoughts clearly
- You learn what it takes to teach others something
- You can parle this into other opportunities... like courses
- It's dang fun (even if it's a lot of work)
The last point is crucial: talks are not easy but they are rewarding in many ways. There's a spectrum: internal talks maybe don't need as much polish as public ones but there's still time needed to research, write code, and learn.
Tip #8: Read books
Now we are starting to venture out into "using non-work time for work" territory but I think this is on the edge. There are many books you can read for your own edification that will translate to an impact at work and still be fun to read.
Books I've recommended before like Atomic Habits or Make Time will help you with life optimization but then there are also books like Code Complete, the Ultimate Tome on software design, that will help you professionally. I love non-fiction books, something I probably got from my parents who are avid readers.
Should have done this earlier, making a thread to keep Code Complete notes for key points or stuff I want to bookmark for presentations.
— Kamranicus 🧙 (@kamranayub) January 3, 2021
Tip #9: Have some side projects
Alright, now we are solidly in "non-work time" suggestion mode. Not everyone wants this or can even do it (though, if "I don't have enough time" is your excuse, see Issue #5 once again).
For myself, I've found success maintaining a few long-term projects like Keep Track of My Games, contributing to open source like Excalibur.js, and then my coursework usually involves deep learning on multiple subjects. This is mainly because coding is both my profession and hobby. I'd sooner write code than watch Netflix but again, that's me and maybe not you.
Through these projects I learned about things outside work: TypeScript, maintaining open source, React, Azure, RavenDB, Gatsby.js. I would not even have my current Target job I expect without having spent 6 months rewriting KTOMG in React to learn it properly.
Time is what you make it
Learning time can be found in many places. After all, it's in the eye of the beholder, and you're the beholder, as my friend likes to say. We keep telling him that's not what the saying means but he insists he's the beholder. 🤷♂️
Let me know in the comments if any of these tips resonated!
Saved Links
Glen Patchet
Written by Alex Trost
Sergii Rudenko
👇 NEW CSS-IN-JS LIBRARY ALERT!
— 🧁 Mark Dalgleish (@markdalgleish) March 26, 2021
🧁 vanilla-extract
🔥 Zero-runtime Stylesheets-in-TypeScript
✨ Minimal abstraction over standard CSS
🦄 Works with any front-end framework
🌳 Locally scoped classes + CSS Variables
🎨 High-level theming systemhttps://t.co/V4P4BYRDrE pic.twitter.com/rbw8IlomQi
