Month: September 2019

Improving Our Code: Infrastructure

Improving Our Code: Infrastructure

We can only improve upon something if we can repeat it. Every moment of every day, if we can repeat the same steps, we can refine those steps, improving on ourselves.

When we make a recipe, we can use the defined steps. Oops! This needs less salt. It baked for too long. We can improve the steps by making notes in our recipe, such that we can improve it. The refining is the same in the software world, for our making of software.

In the past, I received a series of C++ source files for a project I did not create. The original authoring team was disbanded. The source files included no definition of how to build it or how to apply specific third-party dependencies. It was written for Windows, and the goal was to make it work in macOS or Linux also. As an aficionado of GNU-based building (macOS/Linux/UNIX), I found myself unable to figure out at the time what was needed in Windows-based infrastructure. Infrastructure code is just as important an ingredient as the source code itself.

We can trick ourselves to check off the “infrastructure as code” checkbox if we include CMake instructions (or similar instructions). It’s not enough! Let’s think about other infrastructure we need in our code:

  • Automation scripts for grabbing third-party dependencies
  • Information about the build machines. This could be defined lots of different ways:
    • Ansible playbooks, to configure a build machine or a test machine (Or other configurations with Chef or Puppet)
    • Dockerfile definition files or configuration files for a container
    • CloudFormation or Terraform files, to configure a small network on the cloud
  • Jenkins configuration files, written in Groovy, for a tool to be able to start building a project
  • Database data file, for use with tests for some initial construct of testing
  • Automation scripts for releasing
  • Automation scripts for tagging source code
  • Automation scripts for creating documentation (like Swagger, Doxygen, …)
  • Automation scripts for packaging an installable product (Windows .msi, macOS .pkg, RedHat .rpm, etc)
  • Configuration files for configuring Apache or php
  • Pull request or issue templates used with your SCM, to ensure consistency with how you explain changes
  • Coding-style configuration file, to ensure consistency of your coding style
  • Anything else you can think of. Be creative.

This looks like a long list. Admittedly, not every bullet might apply to each project, but the more of these items we put into our code, the more we can improve upon.

Self Service: Empowering Your Team

Self Service: Empowering Your Team

My first professional software position was at Silicon Graphics. While there, I worked on a team building internal tools for the electrical-engineers I worked with. We worked closely with those engineers to help them organize all their data to build circuit boards and integrated circuits.

Also on my team was an administrator of databases, tools, and our SCM tool. He tried to describe to me what his role is, and he said, “I make my work obsolete every day.” At this time in my career, this was very confusing: why would we make our own job obsolete?

The irony of this statement, was that amidst so much restructuring within the company, this team member is not considered obsolete at all. He’s proven how valuable that attitude is, that he is empowering engineers to get more done.

Today, the modern version of this “make my job obsolete” attitude is seen in the 2019 Accelerate State of DevOps Report. In the report it is called “on-demand self-service.” We can see from this research, that getting manual tasks out of the way, developing automated systems, is a powerful way to empower development teams (and end-product users) to meet their goals more quickly.

As a DevOps engineer, I want to ask myself during my work, “Can what I’m currently doing manually be turned into an automated process?” It’s the same attitude of making myself obsolete. It’s the same attitude of “self-service” taken from the State Of DevOps reports.

The automation of tasks that empower developers to do self-service might be labeled “Technical Debt.” I’ve been on teams with product owners that balk at the cost of technical debt. This kind of technical debt is priceless: manual work is time-consuming, error-prone, and could require documentation or training. Automation of those tasks frees engineers to get more done with less effort and greater precision. This is a huge win-win for everyone.

P.S., the “Accelerate: State of DevOps” research is an incredible resource to review. If possible, add your team to the research findings. It is potentially quite powerful for your team’s growth and your end users. I’ll write more about this in future posts.

Making Remote Work. For Everyone

Making Remote Work. For Everyone

If you’re a software engineer, you do remote work. Yes: you.

Even if you come into your office everyday, you still do remote work! Chances are, one of your colleagues works remote on a given day. You might have someone working from home for the day, someone who works every day from their home, or someone stuck in traffic during the morning standup. Sound familiar?

Traditional thought says this is not ideal, but there are lot of good reasons for folks to be remote. Above all, it gives employers the freedom to find the very-most talented team members. It also grants employees the ability to manage a family-priority that could be otherwise difficult on a given weekday.

Having remote colleagues is an opportunity for everyone on the team to try and fix the

Five years ago, I would think, “I never could do remote work.” At the time, I was working with a local team that had a few members working from their homes. I subconsciously felt like those teammates were less available to me, but it was my own flawed thinking. I later was forced to be a remote employee myself. I learned from my original perception, and I dove head-first into good-practices of remote work. Let me share that learning with you.

First, I’ll share three practical steps for everyone involved, even if you typically work from the main-office. Then I’ll share four tips for those that typically work from a remote location.

Turn on your camera!

According to research, a small portion of our communication is the actual words we use. Much more of what we communicate is the immeasurable, non-verbal stuff like our gestures and our tone of voice. In our meetings, we have a responsibility to be fully present with our colleagues.

Modern conferencing software use video cameras that are built into our laptops. We need to ensure we’re always using this. If we don’t, the others in our meeting cannot see our eyes or our hand-gestures. If we don’t, they hear much less of what we’re trying to communicate.

Even if you’re the one at your office and the other person is remote, you also need to be seen. Both of you need your camera on.

Your team needs to see you.

Screen Sharing

The best conferencing software has the ability to share screen and even offer others control of our screen. In effect, this is the same as being able to point to our monitor or hand someone else the mouse. These are basic opportunities that should not be lost.

For the record, my favorite-conferencing-software award goes to Zoom. It works on all kinds of devices, including Windows/Mac/Linux/Phone, and it does the screen sharing well. It even allows paid users to “Record to Cloud,” which prevents complicated video-file sharing from our desktop.

Your team needs to see what you’re working on your screen.

Record software demos

Demonstrating our software is imperative. It is part of the best practices of any software team.

Recording demos of our work makes it easy to communicate changes. Those changes not only impact our team, but they also impact users (new users and users that need support). Recorded demos can also help create user-documentation and training materials.

Though this is a good practice generally, it is a specific help when the team is not co-located. Those recordings can be seen any time they are needed.

When you complete a piece of work, make a recorded demo and share it with your team.

Travel. Be there.

For a team member that remotes everyday, it’s important to actually be in person as much as possible. In particular, the first week (or two), it is imperative to be in person. This is a time of trust-building and learning-the-ropes with the new team. It’s also the right time to get hardware, get a security badge, do training, or attend orientation.

I remember my first week at my remote position. Being in the office, I was able to attend brainstorming sessions. My team had a problem testing our Linux-based library. I got to listen to the problem. I have lots of Linux experience, and the team didn’t know it yet. I offered specific solutions to the current problem. An hour later, the whole team got an email from my new colleague that was praising my help with the team that I hadn’t even met yet! I was a little bit embarrassed, but in general, it built a ton of trust. This experience would’ve been impossible from a distance.

Trust can only be built in person. Be present, in the flesh.

Lunch while in person

I noticed that no one scheduled meetings during the lunch hour, because everyone was expected to be eating at that time. Meanwhile, I would often go out to eat while traveling. What a great opportunity to invite someone to join me!

This gave me the opportunity to build connection with individual members, connection that I would rely on all the other days of my work from my remote location.

The key to this, would be to schedule that time before I arrived to my office’s city. The week before, I make appointments with those colleagues. So far, they always accepted, and the time was always well spent!

Build community, especially breaking bread together.

Eliminate distraction

Teammates in the office are surrounded by their teammates. For remote employees, we might be surrounded by family, by pets, and possibly by work-chores that need to be done. Take notice!

It can be most helpful to get a dedicated office space in our home. This should be off-limits to our family. I’m all for a dog keeping us company, but children or spouses can easily become a distraction. Our teammates deserve our focus.

I take the approach of renting a dedicated office space in my town. I found a very affordable office, preventing those kinds of distractions I’d have at home. I cannot wash my dishes. I cannot fold laundry that just finished in the dryer. My cat will never jump up in front of my laptop to seek attention.

In my town, there is a great community workspaces that are for rent called 1Q1. Spaces like this are full of other work professionals with laptops. These might be good option for a short term rental (or even a long term one).

Set up your space to ensure you are focused on your team’s work.

Make your connectedness a priority

It can be easy to take our remote-ness for granted. It’s easy to dismiss being remote as normal-life. If we forget that we’re remote, we can too easily not notice when our team needs us.

During a daily standup, it’s important to notice that our colleagues might need specific help. We need to be deliberate to start conversations the rest of the day. Starting conversations while in person is very human-nature, but starting conversations while remote is deliberate! As a remote employee, we ought check in on our teammates. These conversations that we start with our colleagues can be instrumental in helping them have a productive day.

My manager has taken pride in how I handle my remote-ness. He knew I didn’t take it for granted. When he announced my work-anniversary to my team, he wrote:

Tyler’s ability to remotely connect and collaborate across different teams is amazing. He can be working from Mars and folks who work with him would not feel the difference given his ability, willingness and flexibility to connect as needed.

Listen carefully to your team, and start conversations.

It’s a good mission, that even though have remote employees, we can still be 100% engaged and 100% part of our team. Mission accomplished.

Continuous Learning

Continuous Learning

The world is moving. In our industry, it moving rather fast. Too easily, as individuals, we can be left behind.

On most days at work, I find a preponderance of opportunities to learn. Some days, I’m just putting in lines of code. Those days are sluggish. I tend to get more excited and productive in work-seasons that I have the chance to learn new concepts or technologies.

Thankfully, I’ve worked at a large company, where I can find or meet a colleague that has advanced skill in something we wish to learn. Sometimes, I can use their code as a template for what I need to do. I can also get their help to get me started learning, where that person introduces me to core-concepts. If the sharing is good enough, it can translate into a shared code-base. It can also turn into code-review or pair-programming. It might be difficult to find people in this position, but the work of finding someone like this is worth it!

Sometimes, finding a colleague with specific skill is not available. Certain technologies we need could be be too new. We might also want to learn while we’re between jobs. (Being between jobs is a perfect time to learn new things!) In these cases, we need to get creative. Let’s break down some ideas.

Conferences, Meetups

Nothing beats meeting people in person: people whose professional goals match your own. We can extend our professional network, learn about how others are solving problems, and learn about great new solutions.

Many conferences have add-ons for training. 10 years ago, I attended a conference that included also a boot-camp to learn Jenkins, a tool for building software. It meant a few additional days of travel and a little additional money, but the benefit of getting hands-on training was huge.

Some conferences are expensive, but take heart! In many cases, conferences are streamed live or available on video. Consider, for example, QCon, a software conference in San Francisco. All of their 2018 talks are available online. This does prevent us from meeting other professionals, but the great core learnings are available. They can also be shared with our teammates.

Many urban areas have great meetups! Consider a meetup in Boston called TechBreakfast. At this kind of meetup, we see both new software concepts and investors meeting in the same place. (Not to mention free breakfast) This is a huge win for all attendees. Is there a meetup like this in your town? If not, what kind of technology meetups are in your town?

Online Learning

Most of us on software teams are no longer at university. We cannot easily enroll in a university class. Happily, we have many opportunities to take classes. It’s easy to find what we need! Many of these courses are cheap or available with a free-trial.

Besides these courses, many companies that promote technology also make helpful videos for their technology. Consider, the following:

These are just a few that I found. Take a look on YouTube for what you need. Lots of folks make videos about technology, but the best documentation comes from the original authors of the technology.

Learning doesn’t have to be about taking courses or attending conferences. Learning happens when we face any kind of new challenge. What kinds of ways are you learning?

What makes you tick?

What makes you tick?

Our brains are always running. Yours might be running on the next obstacle our team faces. Maybe it’s on a new approach to testing code. It could be running over a next great date idea with your spouse.

What’s true is that our brains are always working. Our thoughts have patterns to them. Understanding those patterns empowers us to organize our thoughts and direct our paths, not just in our teams but also in our homes and social lives. In my journey, I’ve made huge advances in understanding how my brain works and what gets me going.

Four years ago, I traveled back to the town I went to college. I was having a rough patch in my life when I sat down with my friend Brent. He helped me do some analysis of the things I’m passionate about. He made some observations. He noticed that when I was in college, I used to be an advocate for an environmental-advocacy group. He paired that with another I was doing at that time: I was a public advocate to motivate people to make care packages for unfortunate kids. The causes were different, but the work I was doing was the same: public speaking and advocacy.

Brent and I share the same faith background. He called it a “God-created-identity,” that we can identify a specific purpose we are made with. With this identified, we can much more clearly pursue our goals around what motivate us.

Since that time, I’ve undergone many different personality tests. They’re typically a little fun and they take a little introspection. How do we tick? They help us understand what makes us unique. In software teams, we each need that uniqueness to bring our best to a team. When we can identify our uniqueness, we in fact bring more of ourselves to the table.

We also ought support each other’s uniqueness. My colleagues are different from me. That’s great! Our team is stronger from our differences. It can be a challenge in some ways to resolve differences, but we bring much more to the table when we embrace those differences and understand unique perspectives.

In the professional world, a commonly used personality test is the Strength’s Finder survey by Gallup. It is helpful for an individual to take those strengths to understand themselves better (I will leave my strengths in the comments section of this post). Most likely, knowing your individual strengths is helpful for a career-direction standpoint.

To take it to another level, an entire team could take the Strength’s Finder survey. When I know my colleagues’ strengths, I can reach out to them for different kinds of challenges we face. They are often better equipped or more passionate about certain challenges, and the net result for the team is greater strength.

“Know thyself” is an old adage. It is no less useful today than it was in ancient Greece. We empower ourselves for greater things when we can better understand how we operate and how our team operates.

Software Best Practices. Shared.

Software Best Practices. Shared.

The world is better when we share ideas.

The best teams advancing the most innovative ideas are teams that listen carefully, share their ideas (even the ideas that seem crazy), and get curious on how to advance their best ideas. This is difficult, because our world of technology is fast-paced, when seen at a high level. We see our neighbors create incredible ideas, and our first impulse is to work harder to try and compete. Hard work has value, of course, but the competitive mindset easily puts us on the wrong track.

Competitiveness and hard work at our desks often means we stop collaborating. It also means the “crazy ideas” we might have get stored away for a future day when it’s more safe to create. (I’ll share more about Psychological Safety in teams in a future post)

I am a “Type 2 Enneagram:” my goal is to help others. In my work life, my goal is to help professionals like me get better at what they do. They wish to help everyone around them get the best outcomes. As a software-professional, this is a true passion of mine. I’ve found this best as a “DevOps Engineer” or “Build & Release Engineer.” Having a role like this, I help ensure the developers around me get their software out to production with:

  • Great ways to collaborate and plan their work. I can be passionate about certain Scrum ceremonies, and how we can truly bring our best at each iteration.
  • Great ways to store and share our code. Writing code is easy. Sharing code in a group is not always easy. It takes care to be respectful in the issues we write and the pull-requests we review.
  • Great ways to test our code. There are SO MANY different tools to ensure our code is of good quality. Surely, there are many tools I’ve never heard of. There are pitfalls and gotchya’s to each, and when we discuss our best outcomes, we start making our test-code really lock down the best code.
  • Great ways to deploy our software. Truly, we cannot improve what we deploy without being able to repeat it. The process of compiling, signing, packaging, testing, and releasing our code has so much infrastructure embedded in it, and our best practice would be to encode all of that infrastructure: “Infrastructure as code.” Once codified, we can truly improve it for every release.
  • Great ways to collaborate. Colleagues are all over the planet, and even if they’re local, colleagues often work from their homes on many days. There are rich technologies to collaborate remotely. Often, we put up barriers to collaborating well: we’d rather not turn our camera on. We’d rather not reach out to that colleague we’re so different from. To bring out our best, especially as engineers tackling complex problems, we must overcome these barriers.

With this blog, I hope I can share lessons learned, and hear others’ share their lessons learned. We each have unique ways we’ve tackled these kinds of problems. We are technically diverse, and there is magic in that diversity. I hope by creating a forum, we can each bring out change us that bring out our best.

I look forward to the conversation.

-Tyler

Theme: Overlay by Kaira
Houghton, Michigan