Currently, the course topic is relevant. The paradigm of “containerization” or releasing your software as self-contained collections of related packages and dependencies called “containers” is catching on quickly across services in the industry. Even though this says it’s for Java developers, it’s not really Java specific. All the concepts and commands used are language independent to a certain extent. The part that the course missed out on was Kubernetes, a fast growing solution from Google related to container management.
Is this particular course a good use of your time to learn about Docker? Maybe. A lot of the content was easily found in documentation or by searching online. If you like information presented in sequence with context, yes, this is a good choice. Otherwise, it may be tedious or too shallow in topic coverage.
The course follows a mini-lecture with demo format. You can copy the course materials and follow along with the demo. The course starts off assuming you don’t have Docker set up. The content begins with installation and follows a simple web app through containerization, deployment, release and scaling. It further goes through monitoring options and maintenance commands.
I did a 5 minute lightning talk at a women in tech conference. Here’s the blog version.
Everything that irritates us about others can lead us to an understanding of ourselves.
As Carl Jung points out, we can learn a lot about our likes and dislikes by paying attention to the things that irritate us. That is more or less how this works.
3 Simple Steps
Step 1: Collect
Before we can answer any questions about what we like or dislike at work, we need to collect data. According to The Paradox Of Choice, a book that explore our biases when remembering experiences and making choices, we judge whether we like an experience based on our feelings at the end. If you had a mostly bad day at work but the last hour or two were great, you might think you had a great day. For that reason, I recommend using mindfulness to collect data based on small tasks or events in your day rather than trying to decide whether you like your work at the end of the day, week, or month.
How does this work?
Building habits is hard. According to The Power of Habit, the best way to build a habit is to associate it with an existing trigger. For example, your trigger might be checking your phone or going to the bathroom. Every time you do this, take a second to use the mindfulness technique to record data about your feelings about your job.
If you’re not familiar with mindfulness, don’t worry: this is really tiny aspect used as a focus tool. First, you need to remove distractions. I use physical sensation to draw attention to right now. Hold fabric between your fingers and rub them together to really pay attention to the texture of the cloth. You can draw one finger along the inside of another finger to generate a sensation that grabs your attention. Bringing focus to a physical sensation is all you need to temporarily dislodge yourself from the barrage of thoughts about everything else but now.
Once you have your attention, do a “body scan”. This is reading your own body language. Are your shoulders tensed or relaxed? Are you breathing slowly and deeply or quickly and shallow? Are you fidgeting or balling your hands in fists? A lot of these little things are easily noticed if you take a second to pay attention and tell you how you’re feeling.
Each “record” should be a pair: what were you doing and how did you feel after. These can be as detailed or sparse as you want. As you repeat the exercise, you will be able to adjust according to what data is most useful to you.
One on one with manager: happy, relaxed, confident
Meeting with stakeholder: tense, crossed arms, needed to take a walk
Publishing code review: godlike
Release war room: why do I do this job?
Step 2: Categorize
Next we categorize the data. There can be 2 or more categories and they can be whatever you want. My favorite is “good vs. bad” but other useful ones are “stressful vs. calming”, “energizing vs. draining”, or “empowering vs. demotivating”. Depending on what you want to change or understand, you can adjust your categories. This technique can be used to sort your activities into groups like “helps promotion vs. busy work” or “builds skills vs. menial tasks”. These can be used to stay on track for career goals.
Publishing code review
Figuring out root cause of bug
Successful release to production
One on one with manager
Meetings with stakeholders
Writing integration test for legacy features
Release war room
Step 3: Interpret
Finally, figuring out your dream. I can’t promise this will get you the best job in your next career change but if you do this regularly, it will make you more aware of what to change now and look for in the future. How does that work?
From the example above I can see a few trends:
I tend not to like meetings
I have a good relationship with my manager
I enjoy releasing code and moving code along in the development process
I enjoy solving problems
I don’t like being in high stress situations like war rooms or situations that may be otherwise delicate like retrospectives
I tend to prefer solo tasks
It looks like I prefer smaller meeting sizes
I might have a good relationship with my manager but not my team based on the retrospective being in the “bad” column
I might not like partner teams if the war room and stakeholder meeting both fell under bad
I probably like our development infrastructure since I liked publishing my code review and releasing my code
If you see the complex ones with “might” and “probably”, you might need better data around those events.
Now, I have this blurb to put on my LinkedIn profile:
I am looking for a position that values independent workers who work closely with their core teams. I enjoy working for managers who empower their engineers to stay focused on their project work. I prefer written communication to meetings and I’m strongly in favor of remote work. I am passionate about devops and development process excellence. I gain great satisfaction from a job were I can problem solve when digging into the root cause of issues.
It sounds like my likes and dislikes at work make me a perfect devops, quality, or infrastructure engineer on a remote team that values independent workers. When I first did this exercise and saw this data, I was on a team that prioritized frequent collaboration across multiple teams and mandated feature development over process or product improvement. This might explain why I wasn’t so happy there.
This also leads to key terms for a job search:
Independent, single manager or fewer managers, written communication, devops, operational excellence, remote, debugging, quality
Here’s an random job for a Remote Security Engineer at Elasticsearch. Let’s see how many of those traits I can find (I’ve bolded the relevant parts):
Engineering a distributed system that is easy to operate via elegantly designed APIs is a challenge. It requires software development skills and the ability to think like a user. We care deeply about giving you ownership of what you’re working on [Independence]. Our company believes we achieve greatness when they are set free and are surrounded and challenged by their peers. At Elastic, we effectively don’t have a hierarchy to speak of [Less multi-manager meetings]; we feel that you should be empowered to comment on anything, regardless of your role within the company.
What You Will Be Doing:
Evolving the security features of Elasticsearch.
Implement authentication, authorization, and other security protocols within Elasticsearch.
Build the foundation of security for the Elastic Stack using knowledge of cryptographic primitives and security trade-offs.
Prototype new ideas and experiment openly.
Collaborating in the open with the Elasticsearch team, Elastic Stack users, and others supporting open source projects.
Working with the community on bugs and performance issues and assisting out support engineers with tougher customer issues. [Debugging]
Tally this up: remote, independent, few multi-manager meetings, quality (comes with security), and debugging with customers. This basically meets everything but the devops requirement. Before I did this exercise, I wouldn’t have looked for or considered this job. It looks like a much better fit for my likes and dislikes than my job at the time was.
Finally, you don’t actually need to leave your current job to “find” your dream job. If you bring this data to your manager, you can have a conversation to improve your current day to day work.
Hi Manager, I really enjoying improving and augmenting our development infrastructure. Is there any bandwidth for me to spend more time on tasks like this?
Dear Manager, I find the stakeholder and war room meetings with Team X are very chaotic and distracting. Do you think you could help me push for a conference call so I don’t need to be in the room and be less distracted?
To the Manager whom it may concern, I understand that you’ve been placing me in leadership positions for several new products. While I think this is a great compliment for the trust you have in me, I want to work with you to make time for doing what I love at this job: crushing bugs and solving problems.
How you phrase these has more to do with Crucial Conversations than anything else. At the very least, you communicate what you want more of or less of.
Brush Twice, Floss Once
How often should you do this? I recommend 5 to 10 consecutive business days with a handful of measurements per day to get a good sense of your average work day. Be careful of the time frame you choose. If another significant life event is going on or something else is changing, you may be measuring your reaction to that other thing instead of your reaction to your job.