Becoming a proficient engineer involves continuous learning. With 7 years in, I believe I have a great deal of learning left behind me. Ironically, the more you learn, the more you know what is left to learn. And so I keep learning.

In this blog post, I invite you to join me on my journey to becoming the best product engineer I can be. To achieve this, I've looked back on the year 2024 and identified several fields I want to focus on in the coming year. In the post, I explain what I will be focussing on and how I will keep you involved. I will sum up the fields that I will cover to give you a glimpse of what is coming.

  1. Writing (in public)
  2. Product Engineering
  3. Open-source contribution

Writing (in public)

I've always been a bit conflicted when it comes to stepping on a stage. Be it a presentation, a report, or a blog, doing things in public is something I find hard to do. Though I am hesitant, I also feel attracted to it somehow. I noticed that people further in their careers tend to write a lot more than I do - to share their knowledge or to show off their skills.

I want to get better at this. I think it's beneficial for my career to be able to share my knowledge and grow my online presence that way. It's not only for the bit of renown you get within the community, but it also proves to potential employers that I know what I'm talking about.

A great example of someone with a great habit of writing is Dan Abramov. Not only does he share his knowledge through his blog overreacted.io, but his online presence on BlueSky and, previously, X has been highly influential. As I have been using React during most of my engineering career, it must come as no surprise that he is someone I take as an example.

I plan to do the following things to improve my writing skills:

  • Maintain this blog (first step taken!),
  • Engage more on social media

Product Engineering

Recently, I came across a company called PostHog. It's a startup building a product with which you can analyze the performance of your application. They're a firm believer that engineers should be involved with product development a lot more than traditionally had been done by the industry.

What makes [product engineers] unique is their focus on creating a product for users. They care about building a solution to problems that provides value to users. They must be empathetic to users, and this means caring about user feedback and usage data. - PostHog

According to this definition of the role, a product engineer should not only develop code but also talk to customers, do some basic design, determine what feature to build next, and so on. Also, the product engineer is responsible end to end for the feature delivery - so not only frontend or backend.

Once I read this definition, I know this is what I've always wanted to be. Currently, I identify myself as a full-stack engineer - with a little hinge towards the front end. Though I really like the work involved with being an engineer, I always wanted to be involved more with the product side of things, too. Figuring out what to do next and changing parts of the design when the UX asks for it are examples of responsibilities that traditionally aren't part of the mandate of an old-school engineer.

What is a product engineer (and why they’re awesome) - PostHog
Startups see their path to success as building a product many people want and pay for. Out of this need came the role of product engineer. They are a…
PostHog

To read more about PostHog's definition of a product engineer, visit this page. They're awesome!

Of course, I could have meddled more with the design or the product strategy by voicing my opinion. This input would undoubtedly be valued, but in the end, the engineer implements what the product manager gives priority to.

And that's something I don't believe in. Luckily, it seems that I am not the only one.

To become a better product engineer, I want to further develop the following skills:

  • Do more design work,
  • Gain more experience with data driven decision making,
  • Focus more on getting it done, in favor of making it technically elegant.

Open-source contribution

Most of the awesome pieces of technology I use are open source. That means that I heavily depend on the work of engineers spending their free time on maintain a project.

Not only do I want to give back to the community, also I think it's a great opportunity to learn. Popular projects have a well established way of working and most of them have a high quality threshold. Getting used to this level of engineering can only be beneficial for my personal development, and thus for my career.

I've already done some contributions, but they've been rather small. My goal for 2025 is to get at least 1 pull request merged at a bigger open-source project. Maybe Ghost, the engine upon which this blog runs, is a good starting point?

The road ahead

One thing I've learned, is that you shouldn't be expecting change to come immediately. Instead, you should make small steps toward your ultimate goal. These little steps compound and will turn out to be a big step in hindsight.

In that light, I plan to do one blog per month, sharing my progression per field. That way I will at least tackle the "writing in public" learning goal.

There you have it! Thanks staying with me until the end of this blog. If you have tips on what I can do to develop myself in the said fields, please don't hesitate to reach out. Part of what makes this journey exciting is that I do it in public. I invite you all to chip in and learn along.