Testing The Limits: My Road From Developer to Consultant

DevOps, growth culture and T-shaped evolution are more than just buzzwords if you’re willing to work on your skills and confidence.

Having spent almost four years here at Brainhub, Krzysztof Jendrzyca has seen it all.

In his path from a full-stack developer to a fully-fledged technical consultant, he tested different technological waters, changed his approach to software development, and learned how to work on his confidence and communication skills to make a shift from coding to working closely with a client.

And while all this may sound just like we’re just about to paint another pretty picture, the truth is, this wasn’t an easy road to follow.

Now that Krzysztof has decided to move on and start another chapter in his career, he found time to sit down and talk about some of the problems and challenges he faced during his time as a Brainhuber.

Q: You started out as a junior developer and after a few years became a technical consultant. Many devs nowadays embark on a similar career path. What made you decide to steer in this direction?

Krzysztof Jendrzyca: To be honest, this wasn’t really a deliberate decision. All I knew right from the start is that I want to be a really good programmer. I started looking for places and people that would help me get there, let me grow and learn new things.

As it turned out, some of the best programmers I knew at that time worked as technical consultants. I observed them, analyzed their skills, habits, and mental models, and later did my best to apply them to my own practice.

Then at some point, someone decided I’m good enough to take the role of technical consultant myself. And so here I am now.

Which of those skills and habits you mentioned were most essential for your growth?

I guess I could weasel my way out of this question by giving a short and generic answer like “soft skills”. Problem is, when it comes to soft skills, there are so many of them it’s really hard to pinpoint the most essential.

The more I think about it, the more I realize that what led me to where I am today was developing a more straightforward approach to my work.

Throughout the years I learned to drill into details and boil them down to the essentials so I can see things as they are. I don’t romanticize programming as a craft too much.

This mental model is called “reasoning from first principles’’ and was popularized by Elon Musk. Even though he could easily buy rockets for his SpaceX projects somewhere else, he made a decision to build them in-house. He started with a simple question: “what is a rocket made of?”, and then broke it down and reassembled it in his own, more cost-effective way.

This is exactly what I did with my skills and competencies in order to find areas I could improve on. To quote Tim Urban from waitbutwhy.com, thinking this way lets you stop being a cook that only follows recipes and start to act more and more like a chef who invents them.

The key here is taking a low-level perspective. Once you fully understand the process, you can better assess your skillset and reassemble it in a way that best fits your role. I don’t believe in all those telltale stories of lone genius programmers anymore, because now I see that growing your skills boils down to consistent and habitual work.

It may not always be easy, but it’s always possible — and all the mythology behind it mostly serves as an excuse for giving up.

First principles also helped me with looking more critically at frameworks and libraries I use in my everyday work. I now try to see through the logic behind them, to understand the very purpose they were created for in the first place. This way it’s much easier to choose the right tool for a project or to find the right solution within specific frameworks. I can tell if a library follows the basic principles of software engineering and verify the hype behind some new technologies. Goodbye, cargo cult programming!

Becoming a technical consultant means switching from just coding to direct communication with clients and other stakeholders in a project.

Was that difficult for you?

There are two things I found especially challenging.

First was absorbing the fact I can actually say things like “I don’t know, I will have to get back to you on this” or “The solution you’re proposing isn’t going to work”. Learning to communicate this in a myriad of ways, each of them more polite than the other, has saved me from many tough spots.

I started with the wrong assumption that the customer is always right and that I have to know everything at all times.

But pretty quickly I learned that my own knowledge has its limits and it’s always better to ask someone else than try to bluff. It’s just more honest. The same goes for telling clients when they’re wrong — it’s what they pay us for! After all, we’re consultants, not code monkeys.

The second challenge was finding the right balance between talking to people and doing actual work. There were many days when I spent all my time on meetings, calls, and Slack conversations. That’s only natural when you’re getting more experienced: talking, strategizing, mentoring, and working out fixes and workarounds is simply part of the job. But at the same time, I often felt in a squeeze, like I didn’t have enough space to deal with my own tasks.

What helped me was defining my own work principles and sticking to them. This wasn’t easy, as it often meant I had to turn down requests from colleagues. But with time, they too adjusted to my workflow.

Plus, it’s not like you’ve wasted a whole day if you didn’t write a single line of code. Talking to other people is an important part of a developer’s work. You helped a less experienced colleague fix some bugs, planned your work for the next 2 weeks, and sat down to discuss a design for a key app feature? You really did a lot and shouldn’t feel guilty at all.

Shifting into an agile environment where you talk to clients might take some getting used to. It’s a new situation that sometimes feels uncomfortable: like something is blocking you from speaking during a meeting, even when you know exactly what to say.

Any tips on dealing with that?

If you’re feeling blocked in these types of situations, the problem might be one of two things: either you don’t fully trust yourself and your skills, or you simply don’t know how to deal with a particular task.

In the first case, try to push yourself a little. Once you’ve successfully tackled a challenging task, you’ll get the validation you need. And if you feel lost, just stay patient and do your best to learn everything you need to deal with a problematic assignment. Most of the time you’ll see that it’s much simpler than you initially thought.

I noticed that many developers often have problems with keeping conversations flowing when they talk to business people. I had struggled with this, too. I learned some catch-all responses, like “Sorry, but I’m not sure I understand this”, “Let me rephrase that”, or “Let me make sure I got it right”.

While they may sound pretty simple or even banal, they can really help with pushing the conversation forward. Even in situations when I don’t know what we’re talking about or get completely tongue-tied, there’s always someone who corrects me or explains something in a simpler way. These few phrases can save tons of stress.

When I started out, I was always afraid of questions. They paralyzed me.

Each demo, review, or even a Slack conversation with a client looked the same: I was absolutely sure that I’m going to make some stupid mistake and embarrass myself, my colleagues, and the whole company. I decided to work on my attitude. Today, even though I’m fully aware of the fact that I only know the necessary 20% that brings 80% of the results, I have no problem with joining lively discussions or changing a client’s mind on refactoring.

Dealing with problems like that is the only way to stop hiding your nose in code all the time and jump into more complex, business-oriented conversations with confidence.

Of course, I’m not suggesting every developer should be a one-man-band — but it’s good to strive for more versatility and be able to save the day when a project manager or a business analyst isn’t around. This is how you become an invaluable part of the team. Flexible and adaptable developers are still a rarity, so expanding your skills will definitely put you in a better position when negotiating working terms with your employer.

Now that you’re a technical consultant, has anything changed about the way you look at the process of building products?

I still think that a technical consultant is simply a developer who continues to grow in many different directions and is able to work across many different teams. So while I can’t really say my perspective has completely changed, I do look at the process of building products through a slightly different lens. I’m able to help out with things that many other developers don’t know about or don’t have time to learn about.

I think it’s only natural that you get more experienced with time, especially when you aim for T-shaped knowledge and want to become a generalizing specialist.

Looking through this different lens, what do you think most junior and senior developers lack or do the wrong way?

Many of them have a problem with confidence: some have too little, while others are way overconfident.

The first group is mostly juniors, who often lack self-esteem and tend to take a back seat on projects they join. Meanwhile, the team could really use a fresh perspective from someone new. They may be able to catch mistakes or help with eliminating some dumb habits others have long gotten used to.

It can be really valuable, so I always try to encourage new people to get more involved and speak their minds whenever they see we’re doing something wrong.

Playing it safe is not only bad for the team — it’s also bad for your growth as a developer.

It’s easy to say all this now, but I used to be a backseater, too: taking only the simplest tasks and doing the same, relatively uncomplicated things over and over again. I told myself I was “laying the groundwork” when in fact I was missing a chance to prove myself and speed up my growth.

You only grow when you test your limits. Simple tasks are for when you want to take a breather.

It’s the same thing with overconfident people: people who want to be perceived as more competent by other team members or, as it’s often the case, mostly by themselves. They throw around “shoulds” and “shouldn’ts” even when they don’t know a single thing about a particular project, and never ask for help.

This type of behaviour has negative effects on their team, their project, and their mental energy, because they self-sabotage and block opportunities for growth.

Overconfident people are hard to work with, but luckily this can be unlearned. And when it finally happens, you often find out there’s a really cool and talented person hiding behind this cocky facade.

Surprisingly, this wise-guy attitude is shared not only by more experienced developers but also by beginners. I met a lot of junior developers who believed that reading four programming books, releasing a pet project on GitHub, and freelancing on the side for a few months is enough to call themselves experts. Again, this type of thinking is a big growth-blocker.

Speaking of beginnings, here’s a question to wrap things up: if you could give your younger self any advice on how to grow as a developer, what would it be?

To slow down, to make sure I write down my experiences and document them online, and to keep asking myself this one brilliant question I came across recently: “Will I love the process of getting better at this?”. I would say that those three pieces of advice are linked together.

For me, the path to growth is like a video game level.

Once you complete your main quest, you can move straight to the next one, or stay a little longer and explore some optional stuff.

As a junior, I was focused on speedrunning my career. I skipped most of the side content and did things that weren’t necessarily engaging, but would quickly get me that senior-level promotion I wanted so badly.

There were times when this made me feel burned out. And even though I achieved most of my goals, I got to a point where I don’t really know what to do next.

If I had asked myself the question I mentioned earlier, maybe I would have realized back then just how valuable these optional things can be. I’m talking about things like keeping track of my progress or taking a deep dive into some technology just for fun.

I wish I could go back and explore some more, but it’s too late now. I just don’t feel that kick of motivation anymore.

Meanwhile, there are people out there who take things slowly.

They try to enjoy their work, find time to rest, and minimize doing things they don’t like. Growing at a moderate pace allows them to explore tons of side content and sometimes even make money on stuff they learn during the process. I know a few juniors who, instead of chasing promotion, used the technologies they’ve just grasped to build their own products.

If there’s a perfect recipe for growth, I guess it’s somewhere in the middle. Overall, I think that by taking things slow you pay a lower price.

Sure, you may lose more time — but time runs out much slower than motivation.

Krzysztof Jendrzyca is a software engineer and technical consultant specializing in React and Node. He’s also a speaker, trainer, and blogger. You can follow Krzysztof’s growth path on his blog skutecznyprogramista.pl (heads-up: it’s in Polish).