<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=12616&amp;fmt=gif">
Shortening feedback loops can turn programming noobs into evolutionists

Shortening feedback loops can turn programming noobs into evolutionists

Marek Kirejczyk is CEO and founder of Universal Login and technical CEO at Ethworks. While most of us were playing at recess in the fourth grade, Marek was programming. His technical expertise coupled with his understanding of the factors that makes people — and teams — successful, is why Marek is considered a leader in the broader blockchain space.

Short on time? Here are the key takeaways from Marek on how to build next-level engineering teams:

  • Short feedback loops and automation distinguish the types of developers: noobs, wannabies, hackers, and evolutionists.  
  • Embrace a "change agent." There are no easy ways to introduce a "short feedback loop" revolution. Developers tend to revert to how they usually solve problems if something goes wrong.  To combat this, bring someone in who can sit with the team to help them deploy code in a leaner way.
  • Short feedback loops benefit both the company and the individuals at hand. This is the best way to improve job satisfaction and reduce burnout. When teams have less development/deployment issues, then companies can build so much more.

What follows is a long form write up of the key topics we discussed in our interview.

“There’s a gap in learning for engineers. In between theory and practice, there are key skills that involve someone’s ability to task or debug, and design the software’s architecture.”

Marek believes these skills in design and debugging are an unspoken part of software engineering — that unlike theory — are used everyday. So what can developers do to excel in these skills?

There are two key factors that make developers either good or bad. The first factor is whether or not they operate effectively and within a fast feedback loop. The second factor is automation — are developers automating tasks as they go?

Let’s start with a couple of things that developers do wrong. Random debugging is a common issue with beginners, but Marek’s “favorite example of what developers do wrong is when they don’t know how to use version control.” Engineering managers need to find a way to effectively manage and merge the team’s work. This is crucial to short-term and long-term success!

“The best developers are the ones who understand that automating is a way to streamline processes. They determine if their code is working immediately so they don’t waste time on debugging.” According to Marek, a “good” developer can write a piece of working code and test it under two minutes. 

“When we hire someone new, we ask them to see if they can write workable code [in under two minutes]. By examining this, you’re testing how people react and seeing what their process is like. This way, it’s a long-term play versus investing in the short-term.”

Regardless of the developer’s role and experience level, the above factors are essential to success. However, it is important to know the different types of developers that you’re dealing with. Here’s Marek’s take:

IMG_0208-1

  • Noobs are developers who entertain long feedback loops and low automation. “I remember when I was 10 I would program for 30-minutes and try to compile it. It would then take me 1-hour to debug the code, which is not very efficient and an extremely slow feedback loop.” Short feedback loops require the entire team to run maintenance all the time — and surprisingly, it’s a working style that mature engineering teams are still stuck doing.

  • Wannabies are developers who do a lot of automation, but don’t have short feedback loops. Oftentimes this type of developer will default to debugging large chunks of code — a disaster if you’re trying to code efficiently. 

  • Hackers are developers who have shorter feedback loops and low automation. They are extremely efficient and have a very good understanding of what they do. They work by isolating a piece of code, testing it to ensure it works, and then putting it back into the bigger problem. The challenge with hackers is that they’re rare, difficult to hire, and their code is high quality, but sometimes hard to understand. Non-hackers might not follow their code so it’s hard to maintain, which is even more difficult if you’re a company trying to scale. Though they are valuable to the engineering community, you should be cautious of the pros and cons of hiring them.

  • Evolutionists are experienced developers who work in short feedback loops and automate code as they go. They utilize test driven development and refactoring in their daily work. “If you work with test driven developers, you can see how short their feedback cycle is. These developers are less performant than hackers and they are less efficient in the short-term — but more efficient in the long-term.” The plus side is that you never end up with bad code.

How to grow your engineering teams

There are whole companies with engineering teams that run slow because they’re doing nothing but fixing bugs. How many bugs can there be?

Working in short feedback loops is something to be expected out of mid to senior-level developer positions. In fact, experience in short feedback loops is a requirement for any developer looking to get hired by Marek and his team.

For junior developers, “it’s best to partner them with a ‘change agent’ because they’re less set in their ways.” 

Marek shared insights from his experience in training people to be reactive. “We noticed that as soon as something goes wrong, they [developers] revert to how they usually solve problems. To combat this, we embraced the ‘change agent' — someone who knows how to handle a situation properly, and can sit with the team to help deploy code in a leaner way.”

“For the best results, focus on the process and find the solution there. That’s how you create a culture of change. It’ll take many months, but as new people are hired onto the team, and with time, it becomes the norm.”

Here's what doesn't work when growing you engineering team:

  • Trainings. These are difficult because they provide an unrealistic working environment that doesn’t translate. What happens when you go back to work and you are bombarded with deadlines? 
  • Wannabies working in pairs. This is better than training but still ineffective.
  • Using buzzwords like Agile to explain structural changes. Don’t use sophisticated words — this can intimidate people.

Here’s what you can do to successfully build your engineering team:

  • Human infection model. Have someone who’s struggling/junior go work with another team that is already "infected" with good practices - for a little while. They might learn a few things and come back with new insights. 
  • Using simple words. Period.
  • Shorter feedback loops. Sit down with your team and have them solve things together, in a group. There’s no easy way to do this — it’ll be hard work, but it’s worth your time.
  • Technical coaching. The goal should be for a “coach” to mentor the team on agile practices akin to tool-selection, implementation, and other processes.

What makes a great engineering team?

Don’t have the same standards for everyone — you need to tailor the qualities that make up a good developer based on the professional experience and stage of that individual.

“If I look at individuals, I look at different things based on the experience level of the developer. For entry-level talent, we look for people with good engineering background and a solid, basic understanding of databases, algorithm complexity, and computer architecture.”

Marek recalled what a mentor once told him: you can’t have a Java developer who doesn’t know the “ins” and “outs” of how Java works. If a developer can learn one language really well, then they can probably learn any language. 

When I asked Marek what makes his teams so much better, he was quick to reiterate that it was short feedback loops applied to the team level. He added, “the one metric that gives you a sense of how efficient your team is, is how often you deploy to production. If you’re deploying to production more than once in a day, you’re climbing a ladder to get there. This means that you have a team that has thoroughly tested the software, executed an automated deployment process, and has confidence in what they’re doing.” 

To “climb the ladder,” you need to understand testing and automatic deployment. Not only will this ensure that new features get released on a quicker timeline, but developers will be more interested in the work they’re doing. Remember, developers want to solve actual problems. 

When you look at big companies like Amazon, Google, or Uber, you see that they can deploy their core software hundreds or thousands of times a day. This is very telling of how prepared the team is, and how well-tested their processes are.

A company’s benefits of a short feedback loop are clear, but what’s the benefit to the engineers who are working on these teams?

“It brings you so much more job satisfaction and less burnout [when you have a high-performing engineering team]. You have less deployment issues and you can build so much more [over the course of a few months] that people actually use.”

It’s a win-win for companies and individual developers.

So if you’re an engineering leader, how do you advocate for changes?

You need to have someone who’s dedicated to making these changes — whether you hire an in-house change agents or have someone on your team play this role. You also need to make sure that leadership recognizes the need and supports this change.

Keep Reading

If you build an organization of managers then I'd be forced to promote you

The heart and soul of Google is built on engineering

Everything you do should tie back to minimizing risk and surprises