Zsombor's journey

This article explores Zsombor Fuszenecker’s story, who’s a Staff Engineer at Craft. He shares his feelings about development, approaches to day-to-day work, a short-lived startup, and also some inside intel about how to be successful at Craft! 🤫

Published:
full-transformed.jpeg

How did you get into development?

I always wanted to build things I could be proud of, but was never good with my hands, so I dug into programming. 

My dad once made a website with a reindeer gif and visitor counter via Word, but when I asked about it, he didn't know how he did it. So I watched some online tutorials, and ended up really liking Flash for small websites and marketplaces. I was a bit sad when Steve Jobs killed it, but oh well… At the time, there was an online marketplace where you could sell projects and get 50% of each sale. I did this as a teenager and also boosted sales by commenting on other projects, which led people to find my products online. This was the first time I ever made any money, around 40-50 000 HUF (circa €115.) 

At university, I studied electrical engineering, but that was short-lived as I realized I don’t really love physics as much as I thought. I quit university after successfully taking the exams for programming and math, and applied for Engineering Management. It covered multiple fields like mechanical engineering subjects, math, chemical and bioengineering subjects, finance, economics; but surprisingly, not programming. I had to take that on by myself. 

After a while, I found I had time for more than just studying; I went to a job fair and met a mobile agency called Distinction. I joined this company soon afterward, which led to Craft, later.

What did you do there?

At Distinction, I was employee nr. 22 and started working on test automation. My plan was not to do manual testing, but I did a lot of it; mainly on Skyscanner-related projects like UI testing, and manually testing iOS and Android apps. After around six months, Skyscanner acquired Distinction, and I was a tester for another half a year. I also took on tasks such as continuous deployments for mobile apps. I realized I didn’t want to do that full time, and got a bit demotivated. 

Around then, I started to get into iOS development on the side in my free time. I made my own iOS app that helped university students find parties based on Facebook events. My manager saw it and asked me to become an iOS developer. 

Then Peti Wiesner (Staff Product Engineer - App team at Craft) started to mentor me, and I quickly started to get pretty hard tasks, like adding ads to apps. Ads were never really my passion, but it was a nice opportunity to learn about this quite messy topic, and the “magic” behind it. I worked mainly on customer-facing products, and

I always put extra effort into creating something that worked really well

For example, I had this idea that I would like to highlight to users that their search for a flight might not be optimal, and that they might be better off going on a different day or flight, if possible. This was not a project the team had time for, but I asked to do it in my free time; I designed and implemented the front and backend APIs, did some user interviews, set up an A/B Test, and then released it. It seems like this has been reworked since, but it’s still available in the Skyscanner app.

Tell us about your startup idea!

After a year at an audio startup, I decided to launch my own company, which leveraged my passion for photography to create a platform that connected professional and amateur photographers. I also had some professional photographer friends who helped me by providing feedback.

Initially, I implemented Stripe and Apple Pay for transactions, founded the company, and submitted the app to Apple. Unexpectedly, Apple rejected it because the purchase item was fully digital, meaning it required in-app purchases instead of Apple Pay. My original plan was for direct peer-to-peer payments with a minimal fee. After a tough appeal to the review board, I had to pivot to a credit system where users bought credits to pay professional photographers. Despite Apple’s approval and the launch of this model, I quickly felt uncomfortable with the credit system because it felt scammy. After the first purchase, I shut it down.

Why did you join Craft?

I was on good terms with Viktor (co-founder of Craft) and Bálint (CEO and co-founder of Craft). They knew about my project and needed someone to take on Release management of the Craft app for the first public release, testing, and some feature development. I was mainly working on the first version of our markdown import/export, image export, copy-paste logic, and subscription UI flow. At first, we took things slowly and I worked as a contractor for 20 hours per week for three months, which allowed everyone to decide if we wanted to work together. I was given a project and some pointers, and we did daily check-ins. After a month or so, they offered me a permanent role and I accepted.

How have your responsibilities changed?

I joined as a software engineer, but I think the plan was that I'd test a lot and manage the releases, so I started doing those things soon after joining full-time. Back then, it took ages to do a release as it wasn't as automated as today. At one point, I was doing too many things, and I couldn't do them all to the quality I wanted. That was a tough time, but we sat down and decided I’d work less on feature development and instead focus on stability, so that when we released a feature, everyone had a peaceful day. The goal was to ensure that leadership didn’t need to think about product stability so much.

How was the shift from feature development to stability for you?

I never saw myself as a developer.

I mean, I am a developer, but I'm mainly a problem solver. For me, development is a tool to solve problems.

For instance, If the problem is making releases stable with better processes, then I'm happy to busy myself with that, even if it doesn't require coding. I never wanted to get too deep into development – which probably makes me the odd one out – but I don't like optimizing algorithms and scaling problems; I'd rather go from 0 to 1, to have something and let the UI and UX work to solve problems. I’m less interested in scaling something from 1 to 100.

l like to work on features and improve them, but I’m not the one who optimizes code or figures out some very deep memory issue. Maybe this is why I didn't become a backend or platform engineer: I wouldn't see the fruits of my work. Seeing a backend response is not as fun as seeing it on your mobile with a nice UI around it. I have some extrinsic motivation for my work, and a json response won’t wow people, but they do understand an app feature.

For me, the fun part of my job is not the development; it’s when something is done and works, and people see it, use it, and give feedback.

How did you climb the career ladder?

I always have this mindset to take as much off my leader's shoulders as possible. If you do this, you usually advance in your career, but it means doing less development and more things that nobody wants to do, like creating runbooks, making a dashboard for monitoring, writeups, reports, planning, etc.

Did you intend to become a team lead? How's it going?

Honestly, no. I've never had a career plan, and I never wanted to have one:

I just want to do better than yesterday.

If I receive constructive feedback, I build on it and ensure to get better, and to not receive the same feedback again.

When Craft’s web project started, my plate was full and we hired someone next to me, although I wasn't ready to become a line manager at that time.

At first, Viktor often came up with ideas and plans for the next week, which was something I could take on because I knew what teams were working on, and knew what our own team needed. By taking on this planning process, I became area lead for the stability team, although people management wasn’t included yet.

Meanwhile, I also picked up incident management. We have this mindset at Craft that 

it's okay to make incidents; just don’t make the same one twice.

So I introduced company-wide post mortem meetings, to treat incidents seriously. With time, we also needed to scale my team because the engineering organization grew, which was a good point at which to start taking on line management. Now, I’m trying to delegate more processes which I’m the sole owner of, and to pick up less straightforward new areas.

What’s the best part of your job?

It is usually things which I disliked at the beginning because these are the unexpected problems which challenge my skills. For example, let's say someone was abusing Craft’s publishing feature for phishing purposes. This could get us put on blacklists of various providers, and even on router blacklists. 

By default, nobody would tell us we’re on a blacklist; they would simply cut off the site traffic. When this happens, you don’t even notice because traffic from those people is not hitting your systems. You are blind and the best that can happen is that loyal users complain that Craft is unavailable. It’s not a coding issue, and not something you can solve with some emails. 

Something like this would be a complex problem, and it’s hard to figure out where to start and to find a long-term solution. It usually involves lots of research, internal and external communication, syncing with other teams, finding out where the issue is, then figuring out a resolution, and the long-term solution. Getting things in place that make our systems less vulnerable to abuses like phishing is extremely rewarding. 

In short, I like the parts of my job where I can figure out how to protect us from problems, long-term.

Do you have principles that you follow from day to day?

I always thoroughly manually test my code. I try to fix it in a way that does not lead to regressions, which I take as a personal failure. As a developer, I might not write the cleanest code, but I try to think about all edge cases and use cases that users can face, and to ensure my feature works how users expect.

With my tester background, I can build great relationships with people who lead projects, as I can tell fairly early if something is going to be a pain to develop, or if things have been missed. In short, I try to help out with project management.

I am also trying to take estimation seriously, meaning that I check my calendar to block out time, then communicate the hours required and the deadline. If I can’t progress as well as I wanted and things are starting to drift by more than 30 minutes, I communicate this and provide an alternative solution.

I try to always stick to what I say, so I might ask for time to look into a new request and estimate how long it would take. I usually group tasks into “must haves” and “nice-to-haves”. For instance, Viktor often comes to me with feature ideas, and I look into each one and give my estimate. I also point out things that might not be “must-haves'' for the first release, but would take ‘x’ extra hours to add. Prioritizing work is more than simply implementing a specification; you can point out UX challenges, issues that users might face, scope, etc. 

Furthermore, good iterative development for a user-facing product is about building chunks of working use-cases which are “pixel-perfect,” in my opinion. So, instead of building five use-cases which all work for a feature, but look awful, I optimize for delivering the first use-case with pixel-perfect quality, and then start on the next one. This causes less confusion in testing and feature development, so it's clear what’s “finished,” and what isn’t ready yet. People can then give feedback on what’s good to go, without judging things still under development.

What makes someone successful at Craft?

Ownership does not end with your area of expertise, and you can't own something properly if you only care about implementation. It’s much better to question and ideate around UX/UI, think about validating new features, proactively check the analytics, and listen to community feedback. Take the initiative when something breaks, and don't wait for someone else to do this. If it's a big issue, but you’re working on something else, just communicate the issue and recommend a solution to your team lead, along with a timeline for a fix, and potentially a workaround for the customer support team to share with users. 

Other important things are good written communication, and being dependable and reliable. If these are in place you won’t need to be micromanaged, which nobody enjoys anyway! Also highly valued are being able to find gaps and propose solutions, and providing meaningful, easy-to-understand context. When people are partners in the decision-making process, it means leadership does not need to think through a problem from zero.

Want to be part of our team? Join us! 🧑‍🤝‍🧑

We are constantly on the lookout for talented new members to join us on this journey. Check out our open roles 👉️ here 👈️ and apply today!

Interested? Read More...