London, day 29: Week 4 as a software engineer

Wow, time flies. I can’t believe it’s been exactly 4 weeks since I arrived in London and took on a job as a software engineer (see here for my post on Day 8). It’s been a month of tremendous learning, growth, and intellectual challenges.

I won’t claim to be a good engineer by now (far from it!), but I’ve gained an insider’s view into the somewhat mysterious and somewhat romanticized world software development. In the process, I’ve developed a deep appreciation and respect for engineers.

What have I learned?

1) Code is king.

To start, I want to reiterate what a PM colleague told me in the first days of being here that understates all my experience:

Engineering is a fundamentally bottom-up organization. If you can code, you are king.

That, to me, summarizes the tech industry in a nutshell. Code is simple, is unambiguous, and is truth. If you think about it, that’s absolutely true: ultimately what gets written in code runs in production. It is also available for all to see and fix.

If you can read code: you can see exactly what is implemented.

If you can write code: you are free to experiment. You can fix things. And you are no longer at the mercy of others.

Takeaway for me: don’t need to be an expert, but at least have basic readability of the codebase I’m working with, no matter what role I am in.

2) Tools and documentation are so well established.

It’s never been easier to build complex software, and this is especially true at Google. I saw first-hand how Google is still a software company at its core — something I see less so in the business side. For one, the sheer transparency makes a huge difference: all internal code and packages are available to every employee to learn from and re-use.

Chances are, there will be an existing package that does what I need. If not, there is probably a Stack Overflow article that answers my exact solution. This level of collaboration and openness underlies the democratized and evolutionary nature of software. You build on others’ solutions.

I’ve also benefited from extensive documentation that is written for my project: comments in code, general documentation that explains the architecture, internal documentation on packages, and external documentation on basic coding practices. It makes onboarding a much easier process.

Takeaway for me: write clean code and good documentation.

3) Software architecture is an artform.

The product I’m working on is a web-based data reporting and visualization tool that’s built on Google Web Toolkit (GWT) and Java. I’ll be honest: I was tearing my hair out the first few weeks. It’s so complex! Unraveling how a single checkbox shows up on the screen means tracing through dozen(s) of Java classes. Grr!

A month in, I’m slightly more comfortable with this framework now. Abstractions and structure in the code makes it much easier to maintain, expand, and optimize. I have deep respect for the engineers that developed the initial architecture.

Working on this codebase made me realize that software and (building) architecture shares more than just names. It does take a software architect with strong background and vision to outline and create the initial design. Selecting the language and framework, for example, is one such decision. It’s very costly to refactor the code further down the line.

Takeaway for me: find a strong tech lead, or at least consult a strong software architect, before coding.

4) Protect “make time”.

Don’t disrupt an engineer during a coding session. Just don’t.

The hard part of coding is not the actual coding, but rather thinking through the logic of what/how to build it. By this, I mean thinking through the specifications, expected behavior, and intended interaction with other modules in the existing code. And this all happens in the head during problem solving.

Conclusion

My biggest takeaway is that I want to code more.

I don’t know if I will become a full time software engineer, but I do know that I will remain in tech, and I think everyone in tech should at least know how to navigate the codebase. It’s no coincidence that many successful PMs come from an engineering background.

Understanding the tools of production behind your product will always be time well spent.