Category: Organizations

Our Pair Programming Experience – or, the first time we nerded out together and learned a ton

Our Pair Programming Experience – or, the first time we nerded out together and learned a ton

by and | Community, Organizations, People, Technology

Pair Programming – What is?

Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently. (Wikipedia)

Why explain our experience?

At the end of 2017, we were both OpenShift Architects at our last employer. We were working on integrating the new-to-us platform with the existing processes of the organization – especially the build, deployment, and release processes. Most of the applications on OpenShift would be Java applications, and all Java builds were done with Jenkins. There was a release management tool that was written in-house serving as a middle layer to control deployments and releases.

Build and deployment when we started, mostly to WebSphere on a mainframe or WebSphere on distributed VM’s.

We (the organization) were also in the middle of transitioning from enterprise Jenkins + templates to open source Jenkins + pipelines. There were only a handful of people in the very large IT division who even knew how to write a pipeline – and we took on writing the pipelines (and shared libraries) that would prove out a default implementation of building and releasing to OpenShift. We knew this would be a huge challenge – if done properly, the entire company could run their OpenShift deploys on this pipeline, and it could be improved and grown as more people contributed to it via the internal open source culture that we were building.

While we figured out what to do, the pipeline just went straight from (the new, open source version of) Jenkins to OpenShift. POC FTW!

We ended up doing this via pair programming – because we work really well together, mostly. However, because we’re both technology nerds and also people/culture nerds, and because pair programming has some push-back from more traditional organizations, we wrote down the benefits we saw.

I know some stuff, and you know some stuff, but basically we’re both noobs…

We were BOTH the little turtle…

The team Laine was assigned to was the team that oversaw Jenkins administration and the build process, along with the in-house release management tool – but she’d only been on that team for about 4 months. She knew more about Jenkins than Josh, but….not by much.

Josh was the one who spearheaded bringing OpenShift into the company, and so he knew a lot of the theory of automating OpenShift deploys and had a rough idea of what the process as a whole should look like.

…basically, neither of us really knew how to do what we set out to do, and actually we didn’t intend to do something that fell into the realm of pair programming. We just already relied on each other for many things, including understanding and processing information, and we both deeply loved OpenShift and saw its potential for the company we also loved. We were determined to do as much as we possibly could to help it be successful.

What We Actually Did

Mostly our plan was to just…try stuff. We followed the definition of pair programming above some of the time – we took turns writing while the other focused more on review, catching problems, and planning the next steps. This was awesome, because we caught problems early just by keeping an eye on each other’s work – like, “uhh, you spelled ‘deploy’ D-E-P-L-Y, that’s not gonna’ work…”

Taking turns doing the actual coding also allowed us to churn through research while still doing development. We’re both top-down thinkers, which means that we understood the steps that needed to happen without knowing quite how we would implement each step. With one of us researching while the other was coding, as soon as one coding task was complete, we could more or less start right away on the next. Given the amount of research we had to do, this was huge in speeding us up. It also allowed us to switch up what we were each doing, and not get bogged down in either research or implementation.

Why is Heath Ledger Joker on this? IDK, who cares?? <3

In addition to taking turns coding vs overseeing, we also did a lot of what might be called parallel programming – we worked closely on different aspects of the same problem at the same time. This was also highly effective, but it required us to be very much on the same page about what we were doing. We did this mostly off-hours, via Slack communication, so…it wasn’t always a given that we actually were on the same page.

Despite the communication hijinks, or maybe because of them (it was really funny…), this was probably the most efficient of all of the coding work we did. If we got stuck or didn’t know how to solve a problem, the other could easily figure out how to help because we were already in the code. We also bounced questions and implementation ideas off of each other (efficiently, because we didn’t need to explain the entire project!), so…something like pair solution design.

And again, up there in overall efficiency, was some pair debugging. We could put our heads together to talk through what was broken (aside from typos…), figure out why it was broken, and land more quickly at the right solution to fix it. (See also: Rubber Duck Debugging)

This is where we landed after we did our part. We advised on tweaking the process, helped implement updates where we could, and…got out of the way and let the very talented and enthusiastic contributing developers take over.

Why it was Awesome

(Quotes in this section are from Strengthening the Case for Pair Programming.)

More Efficient

Two heads are better than one. Often, the part of development that takes the longest or is the most complicated isn’t writing the code – it’s figuring out what to do, and then figuring out what you did to break it and how to fix it.

Having a person there who understands the project as well as you do can speed up…well, literally all of that.

Higher Quality

…virtually all the surveyed professional programmers stated that they were more confident in their solutions when they pair programmed.

Pair programming provides better quality, hands down. We talked about this some already – a pair programmer can catch bugs before compiling or unit tests can, and they can catch bugs all the way from a typo to an architecture or design problem. Pair programming also requires by its very nature discussing all decisions – both design and implementation, at least at a high level.

…basically, you end up with an application where there’s been a design and code review for literally every aspect of the application.

Resilient Programming FTW (or, You Can Still Make Progress Even when Your Computer Dies)

We both had some laptop issues in all of this – Laine had some battery issues, and Josh had his laptop start a virus scan (slowing his computer to the point of being unusable) while he was trying to code. We got on Slack and helped the one who still had a working laptop, rather than that time just…being wasted.

Relationships, and Joy

…more than 90% stated that they enjoyed collaborative programming more than solo programming.

Best nerd celebration emoji.

Laughing at mistakes, getting encouragement (or trolling) when we did dumb stuff, nerd emoji celebration when something went well – all of these were better because we were working together.

It was just…fun. There was joy in all of it, in both the successes and the failures. And there was joy in the shared purpose of setting something that we loved up for success.

When making a pair…

There are a few things we learned that were vital to pair programming going well for us. We think that the following pieces are the most important to a successful pairing:

Trust

Without trust, you lose some of the benefit of pointing out mistakes and instead spend the time you’d gain making sure that feelings aren’t hurt. Based on our experience, we actually think that this one is the most important key to success.

Temperament

You’ll want to find someone with approximately the same temperament and, uh…bossy-ness. We went with Bossy-ness Level: Maximum, but you do you. We both push for what we think is the right solution, and we kind of enjoy arguing with each other to figure out whose solution really is right. If either of us had paired with someone who was uncomfortable with conflict, chances are it…wouldn’t have gone well.

Technical Level/Skill/Experience

Pair programming probably isn’t going to work very well with a brand new associate paired up with someone who’s been in the industry for 10 years. That’s a lot of context to explain, so while this set up is amazing for training purposes, it isn’t the most effective for software delivery.

Lack of Knowledge

Look for someone who knows something you don’t about what you’re trying to accomplish. Laine knew Jenkins and is a Google savant, and Josh knew the OpenShift theory and reads constantly – when automating releases to OpenShift, it was a good combination.

And Finally

Pair programming provides a ton of value. It speeds up development, catches bugs sooner, and aids dramatically in design and implementation. It’s also fun, which is important and sometimes forgotten about in the just deliver more world of IT.

We loved working together on this, which led to much joy in learning the deep knowledge necessary to build a pipeline the whole company could use. And, even better, it worked – teams that joined OpenShift used and improved upon what we did, and those teams implemented continuous delivery on OpenShift. We’re both very sure that we never have been that successful if we hadn’t paired up on it.

Lean Enterprise Innovation

Lean Enterprise Innovation

by and | Leadership, Organizations, Technology

(FYI, we’re using affiliate links to Amazon in this post!)

Technology innovation is vital. It can enable business success – and it can also drive business innovation.

If a business falls behind the technology curve, it opens itself up to the risk of under-serving its customers, and eventually being out-maneuvered and defeated in the marketplace. This happens over and over to businesses, where a competitor’s technological innovation pushes them right out of existence – see Blockbuster (Netflix), and Border’s (Amazon, B&N). Amazon has also innovated while JC Penney has stagnated – department stores could have taken the world by storm via the internet – but their online presences weren’t good, certainly not as good as their competitors, and therefore neither were their sales figures.

…

Read More Read More

Plan Replace Me

Plan Replace Me

by | Community, Leadership, Organizations, People

One of the greatest things about being a leader, for us, is building deep, enduring relationships with the people and teams we work with.

One of the hardest things, for us, about being a leader is leaving the relationships we’ve built. This is a sad, painful process. We love people a lot, and we keep leaving, maybe because there are always more dragons to teach people how to slay.

…

Read More Read More

Why Developers Love SonarQube

Why Developers Love SonarQube

by and | Human Architecture, Organizations, Processes, Technology

We’ve seen a lot of tool transitions across a large enterprise, and one of the coolest examples was changing the opinion of the company we worked for regarding source code analysis. We had a tool that was under-licensed, slow, ineffective, and largely ignored. At best, it was a check box labeled “we’re definitely secure, you guys!” that everyone on the ground ignored.

…

Read More Read More

Libertarian Enterprise Governance

Libertarian Enterprise Governance

by and | Leadership, Organizations, People, Technology

Be Good

There is freedom and peace and pride in being truly good at something.

Not to seem good.

Not to check off the boxes of good.

But to actually be good.

Everyone should have the freedom to be actually good.

Establishing governance philosophy in an enterprise is a tricky combination of “how much do we trust our people?” and “okay, but how much do we actually trust our people?” The fact is, people are going to screw up. Some of them might deliberately try to screw something up, but mostly they’ll just make mistakes. If the organization can’t handle mistakes, that’s a problem with the adaptability and flexibility of the organization, not with its people. This means that people’s potential mistakes are not a reason to default to not trusting them.

…

Read More Read More

Tech Lead Delegation – Baby Steps into Leadership

Tech Lead Delegation – Baby Steps into Leadership

by and | Leadership, Organizations, Technology

One of the first steps a technical leader takes is taking over as a team lead. In IT, this is often called a Dev Lead, Tech Lead, or Architect, depending on a company’s teams and title structure, or it can be more understood than titled.

This type of technical leader might not have direct reports, but accepting ownership of the team’s technical success is leadership, and it’s one of the first big responsibility changes and perspective shifts in the process of becoming a technical leader.

Technical leadership means taking on ownership of a team’s technical success.

In the two-part series Technical Leadership Progression, we defined “technical leadership” differently – if you’ve read that one, here we’re using it to mean specifically the Single Team Ownership phase.

…

Read More Read More

Technical Leadership Progression, part 2

Technical Leadership Progression, part 2

by and | Community, Leadership, Organizations, People, Technology

In Technical Leadership, part 1,  we talked about how someone grows into a technical leader aware of their team. In this post, we’ll continue on to describing a Tech Lead who takes ownership of their teams’ success, and then moves into the higher levels.

…

Read More Read More

Technical Leadership Progression, part 1

Technical Leadership Progression, part 1

by and | Community, Leadership, Organizations, People, Technology

We like patterns. Patterns are cool. Patterns apply to people, and groups, and organizations, and…everything, actually. (L: I could talk about patterns for hours, but I won’t. You’re welcome.)

As we’ve each mentored people into technical leadership and tried to understand how people grow as their leadership role and ability grows, we noticed a pattern with several distinct steps. Because patterns are cool, and because we learn by writing and talking, we put words to the pattern we were seeing.

Before we get too far in, let’s define technical leadership:

Technical leadership is providing knowledge, guidance, support, and strategy to developers, systems, and especially the intersection of the two.

To be clear, it is not project management (although sometimes that’s included) or people/HR management (although sometimes those roles are combined too). 

We’re going to break down what we’ve seen with some diagrams and then some explanation of what each stage looks like. We’ll split the explanation into two posts, because there’s a lot to talk about. This was the reasonable-length version, we promise.

The Progression – the Diagrams

As people gain knowledge in Technical Things, that knowledge tends to reflect these levels – self (as in, “my tasks”), single team and system, multi-team/multi-system, and finally, the enterprise/company as a whole.

People also tend to move from awareness of something – for instance, awareness that their team could use their help on something outside of their usual duties – to ownership of it – like, deciding in their soul places to help their team be awesome.

However, fun fact, the basic pattern we noticed was that people move across these at the same time. So really, it looks a little bit like this, assuming they start at the bottom and hop up the levels as they go:

People move from self-awareness to self-ownership, and then they become aware of their team. Eventually they move toward accepting ownership of their team, etc (don’t worry, we’re going to explain these in detail!). However, this diagram is super complicated, so…

TADA! As people progress through technical leadership, they do…well, this. ☝ Self-awareness to enterprise ownership.

The Progression – the Stages

Self -> Awareness

Ever worked with a baby programmer, or remember when you were a baby programmer? Someone brand new, out of school, who hasn’t quite figured out how to like… understand things and also talk to people? Or, cooperate on a professional team? Yeah. Mastering the basics is vital to all that comes after it. Also to adulting well, which is another skill baby programmers usually need to learn.

Self -> Ownership

The true first step to being a technical leader is to build a reputation for being reliable in the eyes of your team – and that means executing your development tasks well. A wise person once told Josh, “be good where you are.” Get things done on time, ask amazing questions, and learn to love and understand the system you’re wrangling.

If there’s success here, more challenging and complicated work will be offered. Also, interesting to note, most technical leaders never get entirely away from this step or the next. Solid technical skill (and troubleshooting, spoiler alert) always help a technical leader.

Single Team & System -> Awareness

This stage starts at troubleshooter – building a track record for solving tricky problems. This means taking on more frustrating and painful tasks than you strictly have to, and getting good at different kinds of problems.

Basically, this is getting really good at understanding the neuroses of a system, learning how to debug and fix it efficiently and effectively. It also requires a massive dose of stubbornly not quitting.

The better someone is at troubleshooting, the more likely that they’ll become the Help, I am Stuck and  You Know Stuff person – dedicating resources to helping other people. This shift means all kinds of patience – with technology, and with people. A lot of great technical people draw the line here, mostly because…well, they don’t enjoy people very much. That’s fine, people are a lot of work.

This step is where people typically stop doing as much of their own implementation – and that can be really frustrating for people who go into IT to write code. Instead of finding joy in implementation, though, they learn to find joy in other people’s successes. Again, a lot of people draw the line here because they love implementing technical solutions, so please stop talking to them and let them code stuff. 

Next up…

In part 2, we’ll talk about growing into taking ownership of the team’s success, and move on to awareness and ownership of multiple teams.

Building Reliability

Building Reliability

by and | Organizations, People

The definition of reliability for the purposes of this post: other people believing that you (or your team) will:

  1. do what you say you’ll do, and
  2. do what they expect you to do.

Reliability is other people believing that you will do what you say you will do and also what they expect you to do.

Why Reliability?

Reliability is vital to several areas of organizational success:

  1. Successful delegation
  2. Independent execution by teams
  3. Independent execution by individuals

Delegation

When you hand off a task, it’s ideal if you no longer need to think about it – and the more you reliable the person you’re handing the task to, the more likely this is. With reliable people and teams, the default assumption is that any delegated task will be completed. Wouldn’t that be amazing? Delegation backed by a perception of reliability actually clears brains of stress and cognitive dissonance. Basically, people can stop worrying and focus on the work they need to do.

This magical theory applies to teams as well – if a team does the work they own, and they believe other teams will do the work they own, then all teams can focus on their own work. Ultimately this eliminates time spent on “following up” (pestering), and lowers everyone’s stress.

Execution

Individuals and teams who are allowed to execute without being required to explain every step and justify every decision can focus more on doing actual things. Even in the awesome Utopian Land of Reliability, some checking in is necessary, for a lot of reasons – one of the best is to give the leader the opportunity to teach and to reinforce good judgement. However, guidance shouldn’t be a nuisance – it shouldn’t turn into oversight to the point of preventing productivity.

If brains are calm and hearts aren’t worried, people can more easily focus on their work, objectives, and goals – and they execute their tasks more cleanly. When each person or team believes that they can focus on their responsibilities rather than worrying about other people’s execution, this leads to overall organizational success.

Reliability seems awesome! Uh…now what?

Cool, you want to be thought of as reliable so you can do stuff. A key question now becomes: how do you build a reputation for reliability? Or maybe the question should be, can this be deliberately built? Nope! Blog post ends here. Thanks for reading!

Kidding.

Building a reputation for reliability is surprisingly simple. In any relationship, you start at the ground floor, with basically zero reliability. To increase the number of reliability points, it’s like a ramp – a slow and steady upward movement.

The super secrety secret to building a reputation for reliability: make a commitment. Fulfill the commitment. Repeat.

Reliability for Newbs

Start a meeting by saying, “I’ll make a recap.” End the meeting, re-iterating that you’ll make the recap. Then make the recap. Tada! You’ve done a useful thing that you promised to do. Congratulations, you now seem more reliable! People now know that you kept that commitment.

You can do this by doing anything useful – say you’ll do it, and then follow through. For bonus trust points, promise to do it by a certain date and then deliver on or before your deadline.

Reliability Level Up

To continue to build your new reputation for being reliable, continue to keep your commitments. Small commitments can build reliability only to a certain level –  but after keeping enough smaller commitments, people will begin to give you opportunities to keep larger commitments.

These larger commitments, once kept, will give you more reliability points – but they’ll also be more complicated, and take longer to complete. However, in order to build to a high level of reliability, the pattern is exactly the same: steadily fulfill commitments over time.

Team Reliability

Teams can do the same thing, for themselves and for the teams and people they work with. At any time, an individual on the team can step up and start keeping commitments on behalf of the team. This results in a team’s reliability points increasing. The individual can then teach the other team members to keep commitments on behalf of the team. Every commitment kept adds to the team’s reliability point total – and also helps boost overall team morale.

There’s also the team’s perception of the team’s reliability – when this is working correctly, it’s usually when people say things like, “it’s a good team to work on.” Goals are a great way to help build this – committing to goals has the added bonus of building unity, and then following through on those commitments builds reliability. Even if a goal is not achieved, the tasks necessary to attempt to fulfill the goal are completed, and those commitments are kept.

Uh…Whoops. I Broke It.

A reputation for being reliable can be broken. To break it, don’t keep your commitments. Promise things that you can’t or won’t do. You could also just stop doing the things already expected of you – because reliability is both the things you say you’ll do and the things people expect you to do.

Let’s say you fail to fulfill a commitment and you lose reliability points. It happens. People aren’t perfect – but that’s okay, because perfection isn’t necessary here. There are two things that can help repair this break and then allow you to go back to building reliability:

  1. Accept responsibility. Clearly. Be obvious that you accept responsibility for the failure. Hiding from a commitment, hoping no one notices it wasn’t fulfilled, does even more damage.
  2. Renegotiate the commitment. Make a reasonable judgment about re-committing to the task. Does the task still make sense to do? If so, what is a reasonable deadline for the commitment? If the commitment should still be fulfilled, fulfill it.

Ultimate Value

Being perceived as reliable lets people and teams believe that they can do increasingly harder and more awesome things. If we don’t truly believe that we can succeed, we don’t try. When we do believe that we can succeed, we start to watch for opportunities to do increasingly more awesome things.

Reliability lets teams believe in themselves.

Reliability also lets us focus on execution instead of worrying. We can focus more on tailored challenges and working hard, and less on trying to split our focus to all details of all things.

Basically…when we believe that we can succeed (more awesome things), and we can focus on execution (get things done), more awesome things get done. Reliability helps fulfills both of those requirements.

Reliability makes more awesome things get done.

Meta