On knowing nothing

I have just crossed the first 3 months of my journey into the worlds of web development and technology-powered startups. Transitioning over from a background in chemical engineering (what is this?) and being a self-taught coder, most of my energy and attention have been dedicated towards learning the ropes of what it takes to be a junior developer working in teams, which has been a fun and intensive experience so far — making the time that has passed feel more like a year.

Up to this point, I have not explicitly shared about the internal workings of this transitory journey. Moving forward, I would like to use my writing as a tool to further unpack the ideas and questions that are particularly interesting to me — with the hope that these could also be of interest to others who might be seeking a glimpse into the world of early stage startups and web development.

The development team I work within started a new ritual recently, which took the form of weekly ‘codegolf’ inspired challenges. Traditionally, codegolfs are programming challenges designed with the objective of producing the shortest possible source code that solves the specified problem.

Before the group convenes to discuss through the approaches that each individual took, each developer would first throw their best attempt at solving the exact same technical challenge.

These are 3 observations that stand out to me so far:

• The power of individual perspectives
• Humility as a mindset for growth
• Balancing performance today with future maintainability

The power of individual perspectives

The baseline requirement for someone to participate in these codegolf discussions is to have an unique opinion to share with the group, as constrained by the technical scope of the challenge in any one week.

In order to have that opinion, a developer must put in the work in order to produce a solution to the problem at hand. The key here is not expediency, there is no reward for the person who solves the problem first (so cheating via Google or Stack Overflow are not incentivised) but rather the reward is in having a divergent approach to share with the rest of the group. The only reasonable way to achieve this is to work through the problem by one’s self.

Of course, a track record of technical experience does help a developer to create more elegant, more efficient solutions but this is not the end all, be all. Within this team, because the focus is heavily weighted towards having a unique perspective through readable code that also performs well, it makes such forums much more accessible to someone like me, who’s technical experience has been limited to solo personal projects and being self-taught.

If anything, this limitation becomes a strength in some ways too. By not knowing what is ‘industry standard’ or ‘good practice’, which other more experienced developers might leverage off, the solutions that I am capable of producing come from a place of first understanding the problem and then using primitive building blocks to piece together a working solution from the ground up — as opposed to following established paradigms or ways of working.

Humility as a mindset for growth

As it turns out, being the dummy in a room can be super powerful as a learning experience.

I vividly remember the first couple of group discussions like it was yesterday, because I distinctly felt a puff of pride of having successfully ‘solved’ the problem, only to be instantly deflated upon seeing the far more elegant and efficient solutions that the other developers had produced.

‘OK, all of these solutions work. But what is it, exactly, that differentiates them? How did the other developers think through the same problem? How might I learn from this?”

Such experiences can be painful to one’s ego if that is all one cares about; conversely, they can also serve as incredibly valuable lessons in accelerating one’s technical capacity — through rapid expansion of the mental frontier of what is possible.

One important, but implicit, element at play here is the attitude of the group towards technical seniority. Instead of a focus on ‘my solution is the best’, the question at the front of everyone’s mind is, ‘how might we learn by sharing our unique viewpoints with one another?’

Balancing performance today with future maintainability

In development, the word ‘best’ can be highly subjective and nuanced, and you are bound to receive the whole spectrum of possible responses if you were to question a group of developers on this.

In this particular context of code golfing, the goal is to reach a working solution in as few moves as possible — in as few lines of code as possible. While this works for golf, it often is not directly applicable to practicing programming within live and deployed systems, which are built by the efforts of multiple developers coordinating with one another.

Short and concise code might look neat and pretty but brevity is not always aligned with performance and is often a compromise on the readability of the code (which is a subjective gauge on how easily a stranger might be able to interpret and understand the logic that is being presented). More concise blocks of code can be more efficient in performance, but there are other instances where the compressed versions of the same logic not only becomes harder to read but also slower and worse off in performance.

These are important questions for a developer to keep in mind because the work that a typical developer does is often tightly interlinked with other developers and the performance of the overarching system. What this means is that it becomes more and more important to balance the chase of perfection within isolated chunks of code with the necessity of producing logic that can be understood by other people as well as enabling the overall prosperity of the system.

You can choose to sleepwalk through life and accept the path that’s been laid out for you. You can choose to accept the world as it is. But you don’t have to. If there’s something in the world you feel is wrong and you have a vision for what a better world could be, you can find your guiding principle and fight for a cause.

— Bret Victor