Issue #8: Hack Your Day to Learn at Work
11 min read

Issue #8: Hack Your Day to Learn at Work

What can you do as a developer to hack your day for learning at work? I share some tips and insights from my career as a software dev.
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:

Issue #5: Where I Find the Time
In this issue: how I think about budgeting time into fixed and discretionary chunks, what my typical day looks like, and the impact of lifestyle decisions

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.

Fixed time means: meetings, lunch, etc. Discretionary time: sprint work and learning.

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.

You can get work done in the 20 mins between meetings too, right?

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 = => ({
  type: 'learning'
Now does it compute?

"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.

I have a thread of takes from Code Complete

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!

Free April
We’re unlocking Pluralsight Skills for the month of April, so you can build valuable new skills in software development, cloud, AI/ML, DevOps, security and more.
Pluralsight's Free April is back on with 7,000+ courses unlocked
Quit Giving The Client What They Want | Win Without Pitching
A mainstay of some agency new business conferences is a few highly coveted clients on the stage lecturing the agency audience on what they want from their agency partners that they’re not getting. While it would be foolish to dismiss these client entreaties out of hand, it would be just as foolish, …
Sometimes you can win better clients and lucrative deals if you push back on them. Go figure!
Creating 3D Illustrations with CSS - Frontend Horse
We learn how to make beautiful 3D Illustrations by only using CSS and HTML!
I've just subscribed to this site, it's pretty awesome.
ts-migrate: A Tool for Migrating to TypeScript at Scale
TypeScript is the official language of frontend web development at Airbnb. Yet, the process of adopting TypeScript and migrating a mature codebase containing thousands of JavaScript files didn’t…
We didn't use this for migrating but we did take inspiration from Airbnb
A new CSS-in-JS lib has hit the block and looks pretty neat!

Enjoying these posts? Subscribe for more