My two-year-old daughter recently grew into an age when she does not want us parents to help her. Whenever she’s about to do something which we see as maybe too complicated for her, we reach out to help her, to which she reacts: “Myself! Myself!”, waving her hands to stop us from helping her. It feels important to her to try and complete the action herself.

When I started my career in programming, I considered reusing a 3rd party library in my code as being too lazy. However absurd that sounds to me after all the years, I actually thought it’s important to reinvent the wheel. I was rather similar to what my daughter does: I felt I wouldn’t have earned my money if I didn’t actually implement all that code myself.

When looking at this through the optics of values, I suppose my value at that time, albeit completely subconscious, was “I need to write all the application code myself”. Had I realized how the value actually sounds like, I could have probably reflected sooner that it didn’t make much sense - that in a way, it was even against the core of being a programmer. But, I didn’t have a mentor, my colleagues were similarly inexperienced as myself and I had no idea about the concept of professional values.

(It’s hard to remember clearly now, but I actually think I also was worried about being done too early with the task and not having enough to do afterwards. Which, however nonsensical in hindsight, makes me think that I also wasn’t focused on outcomes, but merely doing the work and getting paid hourly - also something which I probably could have reflected if I did some more meta thinking.)

It was a classic example of reinventing the wheel - I felt ashamed to even look at existing solutions for inspirations until I put enough effort to solve the problem myself, because I felt my worth as a programmer is created by solving any problem myself, without looking at preexisting resources, asking for help or reusing a preexisting solution completely. Reflecting back on this, the value probably was “being capable of solving problems from scratch, to prove my competency”.

However much I wish I would have realized much sooner that this is not the best way to being a good programmer, I did learn to be persistent and also to always want to know how something is being done - it sparked a desire to really understand things, which is something that I’ve felt ever since.

The downside of course was that the speed of my progress was limited by my own capabilities - and even though they were expanding, they were baby steps.

A huge step forward in terms of what I could do was when I started to dig into the code of frameworks we were using. It was really high-quality OSS code in PHP and literally every time I took a look at some new part of the framework, I found a pattern which I didn’t know before, felt amazement, joy and immersion in multiple aha-moments. I leapfrogged my colleagues in terms of code quality. I started being the one to come for an answer to. At that time, being thrilled by all the state-of-the-art I saw was possible, I would say my value became “Write the nicest code possible.”

Seen retrospectively, this of course came with its whole slew of problems. I didn’t limit myself in terms of time spent on implementing a solution - conforming everything to the tenet of quality, I considered time to be of little importance in the equation. While this helped me immensely in my hard skill development, I simply lacked the realization that it’s still a tradeoff - tradeoff with time spent.

I loved spending a lot of time in code reviews. I paid meticulous attention to every line I read, contemplating if it was done well enough by my standards - and if not, there were two possible scenarios. Either it was something very simple which I knew right off the bat - I simply explained why this was wrong and the colleague author fixed this. Or sometimes, I just felt intuitively the code was off in some way; at those times I stopped, reflected on what it was that felt off, why it felt off and what alternative I would suggest. My arguments were very solid, I didn’t hesitate to start a lenghty, almost philosophical threads, and I won them, because I paid a lot of effort to prove how my suggested change was better - never overruling the author with “just because I said so”, but always carefully explaining why I was actually right, presenting the benefits in a way to really be recognized and hopefully internalized by the author.

This further helped me be very conscious about the code I wrote and about the code I read, and also formulating my thoughts about it in a very clear way to be understandable and educative. While again enormously helpful for my own development (and dare I say also for the colleagues I did the reviews to), it was heavily inefficient. Reflecting back on it now, I thought being on a noble mission for quality warranties any time spent. This was basically a very tangible demonstration of Pareto’s rule - we probably would have saved 80% of the time if I haven’t focused so much on improving the 20% and just accepted the already good enough code a whole lot sooner.

In hindsight, the problem was that I did think there was a silver bullet solution. I thought in reductive terms of “good” and “bad”. This also further impaired my ability to understand the benefits of the other solution (even if it was “just” the time saved by cutting some corners) - it became an ego thing to push for the best, feeling as some defender of the truth. The ego would also have been hurt by me giving up and not continuing in a debate to prove I was “right” - it became too personal.

Continuing my mission to preach quality, it became my habit to always consider product manager’s timelines irrelevant. Objectively speaking, there indeed was a sense of irrelevancy in the way our then-PM kept setting deadlines without real estimations, sometimes even without consulting us engineers. But the solution to that would have been in improving our communication and rectifying our processes, not in ignoring them as I did. And I could always warrant my delay with the quality mantra. I adopted a guerilla mindset of sorts - “us” engineers bravely resisting “them” PMs on our mission for achieving quality and rightfully ignoring their out-of-touch deadlines. I didn’t realize at the time that the customer was completely missing from my equation.

We’re finally coming to an end - a rather happy one I believe. Through this lenghty journey, I arrived to understand step by step that there’s no us vs them. There’s the customer. And it’s us together serving the customer. I learned to be proud of the code I deliver - imperfect one, consciously, with the right corners cut, ready for iterating upon and with the customer getting their hands on it earlier - and hopefully being a little bit happier thanks to what we built for them. Thanks to ceasing to see engineering and product as two separate worlds, I grew to love being involved in the product, engaging in communications with PMs to actually bringing the best value for the customer. And I believe this actually became my value: Bring value to the customer in reasonable time.

I wonder if someone told me at the very beginning of my career: “Make this your value, it’s a very good one”, if it would have worked. Maybe yes, maybe not. Be that as it may, I’m happy that it’s my value at least now.