The Habit Every Software Developer Should Adopt
Hopefully as a software engineer, you find many aspects of the field to be fascinating and enjoyable. Setting aside this time every day is an opportunity to indulge your interests, explore new ideas, write code for yourself [1], and ultimately increase your potential to create more value in less time. This habit has accelerated the growth of my own career; it has helped me deliver a lot more value at work; but most importantly, it has fueled my passion for coding and software development in general, and has buoyed my spirits in times of trouble or stress or self-doubt.
Success in this profession depends on knowledge and skill. It requires a deep understanding of computer science fundamentals, a smattering of languages, some frameworks, databases, the ins and outs of distributed systems, operational best practices, and so forth. To build a great product, we should also understand the domains we work in, whether we work in eCommerce, the medical field, IoT, robotics, machine learning, biotech, fintech, etc. What's more, software engineering is at the leading edge of technological advances in all domains. If you have an eye to capitalize on this new tech, to catch this new wave of technology, perhaps by starting or joining a startup, then you are well advised to know enough about the tech at the crest of the wave so you can make insightful decisions.
To be sure, I still think the lion's share of learning will happen at work. (and if that's not true for you, you probably need a new job). Nothing can replace the experience gained from writing production-grade code and creating solutions that solve complex business problems. But this is not enough. Work can't always give you the opportunity to learn what you need to know to be successful. You may need to devote time to study engineering best practices; or discover what SOLID actually means; or try a prototype idea; or learn a new programming language; or play with some new AWS service; and so on. Sometimes work may provide opportunities to learn new things that you hare interested in. But more often, it doesn't.
Perhaps you are already convinced of all this, and will already agree that we should spend at least an hour a day honing our skill -- just like we should exercise, eat healthy, get 8 hours of sleep ... who has the time, am I right?
I have some suggestions on how to fit this into your day. But first, let's discuss how to use this time.
What To Do?
Focus your efforts on topics and activities that (1) are fun and interesting to you; and/or (2) increase the value you can deliver at work [2]. I'm going to group activities into four broad categories: study, practice, tinker, and side projects. The reason for this grouping is to recognize the advantages of each activity, and see why it is optimal to balance your time among them to get the advantages of each.
Study
You have a set of mental models about how some area of software engineering works (knowledge), how it can be implemented (skills), and how it should be implemented (opinions) -- or you don't have any models, and you would like some. The goal here is to ingest new knowledge and ideas from external sources so you can refine/update/add to your set of mental models.
Look, this one is obvious. Read books, whitepapers, or blog posts. Watch YouTube videos. Go to conferences. Go to meetups. Ingest raw data, and develop an understanding from it.
Practice
Practice [3] refines and strengthens your skills, making them fluid, possibly automatic (and surely no one loves automation more than software engineers).
Isolate a specific skill, and then repeatedly use it in a simple simulation until you improve it by some metric (do it without consulting your notes, do it faster, with fewer failures, without compile errors, etc). Ideally, this repetition should begin to imprint the skill into muscle memory. It's exactly like doing scales on piano or drills in some sport -- except with code. I suggest picking skills you use on a daily (or perhaps weekly) basis.
Here is a list of a few practicable skills that come to mind:
- A programming language (or subset of the language)
- The APIs of a library, tool, or technology
- Test driven development
- SOLID Object Oriented design techniques
- Design Patterns
- Concurrency (using Threads, Executors, Promises, Callbacks, etc.)
- Using the debugger in your IDE (or other critical tools in your IDE)
- Whiteboarding interview coding questions
- Going from zero to "ready to develop" with a favored tech stack (e.g. a frontend package using ReactJS and TypeScript, bundled with Webpack) -- this is handy for rapid prototyping
- Setting up and using a favored database technology (Postgres, MySQL, RDS, DynamoDB, MongoDB, etc)
- SQL Queries
- Linux command line tools
- Vim
- Docker
- Git
Tinkering
This is where knowledge and practice intersects. You may be studying something new, and you just have to see how it actually works -- or verify it works as advertised. Or you may have a harebrained idea for something, and you want to build a prototype to see if it will work. This is a time where it's okay to write shitty throwaway code.
Tinkering with concepts and ideas is a powerful way to learn by actually doing something. While practice is usually focused on one skill and a few actions done repeatedly, tinkering might combine multiple skills and the whole goal is to try a lot of different actions to see what results turn up. The goal isn't enhance musclememory, but to learn and experiment.
One example of this may be creating a basic "Hello World" tutorial with a new framework or library you are interestedin, or making a toy application. Here's an example of my own tinkering: I was re-reading Java Concurrency in Practice, and there were some examples in the book that intrigued me [4]. I re-wrote the examples, used JMH Benchmarking to benchmark the performance, and then experimented with some tweaks of my own.
Side Project
A side project is a dedicated effort to produce something that you or others will consume, usually as a finished, polished output. The fact that you finish and polish the result is what differentiates this from "tinkering" (e.g. it's the difference between a prototype of a feature vs the actual feature).
Driving a good side project to completion is probably going to take quite a bit of time, and if you constrain yourself to only an hour a day, it may take a few months to finish. You may miss out on the opportunity to go deep on learning about something or practicing a skill -- instead, you will be rewarded with more breadth by covering many of the different areas necessary to complete the project.
How Do You Find the Time?
It seems like we have to make time for everything. Eight hours for sleep. An hour for exercise. An hour for reading. Time for family. Walk the dog. Call your mom. All on top of a job and commute. And if you have kids -- holy hell, do you even remember what free time is like? I sure don't. So how do you find the time for anything else?
At the risk of sounding like a hardass, here's my answer: You make time by trimming the fat. Few people are running at 100% efficiency. Find the low (or negative) value habits that suck too much of your time, and cut down on them.
Cut out Social Media
I think it's safe to say that a large number of people spend at least an hour throughout their day scrolling through social media feeds, posting on Reddit, watching TikTok or YouTube, and so on. This is evident from the billions of pieces of content that are added each day, and consumed, and liked or disliked or commented on. And I think it's also safe to say, of the time spent on these platforms, only a tiny amount of it adds lasting value to people's lives.
If you honestly evaluate the social media consumption in your life, you may discover that you do in fact have at least an hour of time.
Another Idea: An Hour at Work
Some companies -- such as Google -- already embrace the idea of giving their engineers time for self growth. Other companies talk about giving their engineers time, but then never really encourage it or facilitate it. And then others may be completely unenthusiastic about the whole idea. That's okay -- regardless of the company's attitude, they will be pleased as punch with the increased value you will add as you gain more knowledge and skills. This is a case where perhaps the ends justify the means. You could ask for forgiveness, rather than permission -- actually, depending on how much more value you end up adding, you could probably just ask for a raise or promotion.
Your manager doesn't need to be made explicitly aware of this. They don't need an hour-by-hour accounting of your time [5]. Go off, do your job, deliver (or over-deliver) the results expected of you, and they should be happy. If you deliver on your commitments in seven hours instead of eight, and then use that extra time to make yourself more productive so you can add even more value to the company, then that's a win for the company as much as yourself.
Also, let's get something straight: you are a professional. You have complete control over how you choose to allocate your work time to meet your commitments (you even have power to choose many of your commitments). You have the power to allocate a small portion of your day to enhance your skills and knowledge. If you don't recognize that you have this control, then you are limiting yourself to be nothing more than a mere corporate drone. Maybe you think companies want drones. They don't. They want rockstars.
Still not convinced? Still worried about working one less hour per day? Well, allow me to retort: again, trim the fat. Stop going to useless meetings that only marginally concern you (or leave early -- yes, that's right, just get up and leave). Stop saying "yes" to extra bullshit commitments people try to foist on you. Stop spending too much time on emails; only check your emails 3x a day, and timebox yourself to 15 minutes; delete any email that doesn't concern you; limit your replies to 3 sentences -- any more probably requires a more efficient form of communication. If you weren't doing these things before, well then I just found you 5 extra hours per week (if not more). You're welcome.
Some Final Advice
Let me leave you with some final tips to get the ball rolling.
First, make this a habit. Create a trigger for it (perhaps do it every day at the same time), and a reward (you'll get coffee afterwards -- or better yet, you'll review the work you did and bask in the warm glow of your own pride)[6]. And commit to the new habit for at least 3 weeks.
Second, keep a single sorted backlog of things you want to do with this time. Any topic you'd like to learn, any prototype. Every harebrained idea that pops in your head should be captured here (possibly in a separate "maybe later" list). If you're like me, having ideas of what to study won't be your problem -- it will be the constant knowing that you'll never run out, and never have time for it all. So choose wisely.
Summary
Knowledge is power -- but this platitude is doubly true for software development, so acquire more of it. Hone your skills. Tinker on some code, or run a side project. And have fun.
Footnotes
[1] Maybe some would say they already do enough coding at work, and they don't need to do it on their own time. I would argue that the code you produce at work does not always align with your interests, with your idea of fun.
[2] Sometimes there is a trade off in these two choices. For instance, maybe reading Code Complete 2 or Effective Java doesn't seem fun -- but perhaps you are at a point in your career where it would have a high impact on the value you can deliver. On the other hand, you may be bored out of your skull with a project at work, and your mind is screaming for something fun, like tinkering with a prototype. It's up to you to make the right tradeoff.
[3] The Coding Blocks podcast has a good episode where they discuss "Deliberate Practice".
[4] Specifically, I was intrigued by the idea of using immutable objects and a volitile
field to avoid the need for synchronization (it resulted in a mere 3% performance increase in this toy example).
[5] When I worked for a law firm as a litigation assistant and then as a paralegal, I used to account for my work time down to 1/10th hour (6 minute) increments. I had to write up that account with specific diction so as to not be rejected by a client winnowing out billable hours.
[6] I highly recommend The Power of Habit if you want to learn more about habits. It's like hacking your basal ganglia to create little event-driven scripts and macros that run in your subconscious.