I’ve been thinking about what the difference is between thoughts, ideas, information, and concepts.

Then, there’s also thinking, deriving a conclusion, understanding, et cetera. A process that transforms a series of thoughts into a brilliant idea.

One obvious thing is that these are concepts in the realm of mental, mind, and cognition. Borrowing a model from computer science, these are data and computation. So let’s call them:

• mental representation: a structured internal symbol the mind uses to encode something about the world.
• cognition: a mental process that transforms representations across various fidelity levels.

The mental representation can go from low-fidelity to high-fidelity:

1. Senses
2. Perception
3. Information
4. Knowledge
5. Concept
6. Thought
7. Idea

What’s important is not how comprehensive the bullet points are. Rather, the subjective comparison between them in terms of level of fidelity.

The cognition can consist of sensing, perceiving, thinking, and understanding. The cognition process transforms mental representation from low-fidelity to high-fidelity.

There’s also memory in the cognitive faculty. The ability to store and recall mental representations is part of the cognitive process as well. I’m not going to talk about the difference between short-term and long-term memory.

Discrete Thoughts

What is interesting here is that reality works in a continuous fashion. Time flows continuously. Space exists continuously. We sense inputs continuously.

Only when a recurring pattern is identified and categorized, a discrete meaning emerge. If we’re able to capture that and symbolize it with a name, we will have a stable symbol for that specific, discrete meaning. Examples are cat, house, glass, which are nouns. It can also be more abstract such as globalization, hard, biology. What matters is that each of them is different, distinct from the other, discrete.

Logic and reasoning also operate in a discrete context. Computer works in discerete, 1 and 0 (binary).

So I think, the more we can identify patterns, categorize them, name them (symbolization), and segregate the symbols, the more we can gain clarity of thinking.

Strong Engineer

Thinking simplistically, the technical talent of an engineer can be reduced to mental acumen and domain-relevant skills. The ability to hold various complex concepts, performs transformations on them (mental gymnastic!), store temporarily, recall at will, and manipulate it again is the important raw-ingredient. Combine it with domain-relevant skills we get a comprehensive and robust, I’d say, framework how to hone and test an engineer’s technical talent.

Read Investable Candidate for my complete take on engineering talent.

Connection to AI and vector embeddings

One of my criticisms about the AI industry is how the industry heavily relies on vector embeddings, a series of floating-point numbers that we don’t fully understand. We try to derive new training/inference methods, new computing processes (CPU->GPU), and new papers/research on a foundation that’s not robust.

But, thinking about it, we don’t necessarily need to fully understand the continuous blob of floating-point numbers. What matters are the symbols, the distinct meaning of those vectors. In fact, not fully understanding them unlocks the ability to represent reality more completely as floating-point numbers operate continuously. Though limited as CPU has 32/64/… bit limit :)

• Starts with Sam’s love—users chart.

• Continue with capturing the market share.

  • 1,000 engineers
  • dotted box line

• what does scaling to the right mean in B2B vs B2C context

• Scalable architectures vs scalable features

  • B2C → how the systems endure 1,000,000 users
  • B2B → how the systems endure 1,000,000 combinations of use case

• Make something that small subset of people love, but scalable → ensures growth to majority market share adoption.

Remember, worth, value used in here is in its most broadest sense!

Part of my thoughts are formed thanks to my boss at work currently. I’d propose there are 3 dimensions:

1. Technical competency, the ability, can you do it.

2. They care (they give a f), do they want to do it.

3. Vibe check.

Technical competency is mostly about the floor and ceiling ideas in High Floor, High Ceiling Candidates. The concrete skill, expertise. Along with the future growth potential of their ability.

They care. I’d propose 80% of this dimensions is driven by leadership. A leader with strong vision, purpose, well-grounded strategy, and able to part this semantics to people, i.e. strong leadership, will almost automatically make people care. By its nature, people want to do great job. They want to serve other people, to be fulfilled, to server higher purpose than their self. The rest 20%, or whatever minor number that fits, I guess, come naturally from them.

So if they don’t care, employees are unengaged, unmotivated, I’d propose it’s caused by weak leadership. When they are well-engaged, fully motivated, know exactly clear where do we go, they will help achieve the goal of the organization. They somehow even work hard. I have some intuitive sense on why, but that’s a story for another day.

Vibe check. The last point is pretty easy really as it’s subjective and simple. The most concrete way I use to describe this is whether you want to spend time and hang out with them outside of work? You can answer organically without comprehensive measurements, hence it’s pretty clear.

TODO: refine, but clarity is there.

Simon quoted how Apple market their products by starting with stating their beliefs on challenging the status quo and thinking differently. Beautifully designed, simple to use, and user-friendly, the “how”. The final “what” is that they just so happened to sell computers, phones, tablets, etc.

From Accelerate (2018) by Forsgren, Humble, and Kim, there are 3 types of organizational culture: pathological, bureaucratic, and generative. To make the story short, the highest-performing organization, defined by profitability, market share, and productivity, fosters a generative culture focused on its mission. How to accomplish the goal? Everything is subject to good performance.

Armed with this knowledge, I think it’s clear and explicit what the best way to open a demo.

A demo to a director with an influence over 200-engineers strong was coming. This was the reason why I was researching these. We’re building a deployment portal, and we need to demo it to them so they can adopt our ecosystem. We’ve been building this portal over the last 9 months, and we were not quite ready yet to open our product to wider users, by the nature of deployment platform, or because I had some strategic mistakes on my product and technical leadership. So it’s pretty high-stakes, but not really, as I don’t expect them to adopt right away given the maturity of the platform. Hence, the strategy here is to ensure they realize our purpose.

I started by stating our 3 beliefs. These are a set of how we think the reality should work. They strongly resonate with our beliefs, but was still concerned about the feature-set of our platform, i.e. the maturity. This was expected. But, here’s the kicker that convinced me, imagine if we do the presentation on the same month, same day, but fast-forward 1 year, it’ll be super easy to convince them to adopt our tooling.

If the vision and purpose are clear, people will follow. There will come a day when this strategy shines its values. Let the time flow, and I will come back with plenty of evidence.

TODO: refine, fix the flow of story.

TODO: 1) talk about Founder Mode by Chesky; 2) explain the initial journey of building deployment portal.

When I use the term “invest”, I mean in the context of investing one’s time, effort, and energy to a particular undertaking in the expectation of returned values in the broadest sense.

The journey started when I was feeling overwhelmed. I felt I spent too much time trying to control the quality of every single output stream of my team. Until I decided it’s enough and there should be a better way to do this.

There were several ideas popped up in my mind, mostly automating the process. But, there’s a limit to automation a tool can do. Such as linters. Higher semantic such as architecture compliancy, dependency graph to ensure non-spaghetti code, etc. cannot be automated. Rather, it’s an art of trade-off that requires human time to judge and decide.

One particular solution keeps surfacing in my mind from various sources when I tried to find the answer. When I asked my question on Reddit. When I watched a YouTube video from Timothy Ronald (controversial, I know).

That is “delegation”. I’ve been hearing this “delegation” term in all leadership books, articles, and videos. It never clicked with me. But this was finally the first time it clicked and unlocked the solution to my problem.

It may have struck me that I was trying too much to be in control. Everybody has 24 hours in their day, technically 8 hours for a corporate job. It was never a scalable strategy in the first place.

TODO: refine this section

If we make an analogy of a stream, where water flows from upstream to downstream, reviewing code is located pretty far downstream.

I invested time and effort in refining and maturing our processes. Building various checkpoints along the lines, such as low-level design review and specification review. Finally, the code review.

Unfortunately, in my organization, I did not have a dedicated mentor, specifically in leadership. So the journey began.

I have been a long-time lurker in r/ExperiencedDevs. Reading software career stories and experiences. Gaining a lot of insights, and low-key, it was fun reading these posts too. But I was never somebody who wrote answers, let alone wrote a post.

I figured asking questions to validate my ideas on r/ExperiencedDevs might be a good solution. So I asked. Unexpectedly, I got a lot of quality responses. Responses that point out my mistake, gave me insights that I can reflect on, and practical actions.

Reflecting upon it, it was such a great experience to be able to bounce my ideas to the whole world and get responses on them. Improving the quality of my ideas even further.

Since then, I concluded that outsourcing mentors to Reddit is actually a viable plan.

I defined two dimensions to judge a candidate. The floor and the ceiling. The floor is the existing cumulative experience the candidate has. The ceiling is the future potential of growth the candidate has.

A fresher from the top 3 universities can be categorized as low floor, high ceiling candidates. They currently don’t have that much experience. But, the raw intelligence, the ingredients, that can be shaped to be a mature software engineers is the high ceiling.

Meanwhile, another candidate with 15 years of experience with a title of Senior Software Engineer might be categorized as high floor, low ceiling candidates. In their 15 years of experience, they’re “still” at Senior level.

Please notice the quote on “still” in the sense that being a Senior at 15 YoE of and itself is not inherently bad. But, it does signal low future growth potential, which may not be bad if that’s no longer the candidate’s priority in their life.

An example of high floor, high ceiling candidates, that I know of, is a Staff Software Engineer at Google (Chrome) with 6 YoE. Another example is a 15 YoE as a Senior Director or VP in big techs corporation ladder. Or, it might mean young 30s founders with unicorn valuation.

There’s no right or wrong answer. What matters is the fit. Whether the candidate fits the expected requirements of the role itself.

A good hire, I defined as somebody who will ramp-up, contribute meaningfully, and continue to grow in the team.

One thing that stuck to me is that a candidate should be “smart”. But, in hiring, I should be able to have an objective criteria that’s applied across the candidates. So I began the journey of delving deep of what’s smart in the context of software engineering.

I found that measuring just IQ is not a comprehensive set of measurements. Just being smart is not enough to be a good software engineer. So the smartness here needs to be contextualized in software engineering. But, it got close to home to what people understood a smart person is. So I just stuck with the term but slap-on the software engineering prefix, hence software engineering IQ.

We’re actually looking for traits that a person demonstrates. To be more precise, a set of traits. After doing personal research and thinking, I decided the traits that embodies a smart engineer boils down to 3 dimensions:

• Problem solving
• Strong mental model capacity
• Sound logic

Mental model is the capability to represent a reality internally in the brain which entails being able to conduct mental gymnastic on those representation. The analogy I frequently use is given a box of 6 sides and 6 colors, if I give you a sequence of flips and I ask you what’s the color on the top side, that’s the mental capabilities.

A practical example why this matters is, says one of the upstream service dependency failed which cause our service to fail as well. We need to be able to reason quickly how does that service failure cause our outage.

This is why I think a lot of people misunderstand “Leetcode” question used in the interviews. Though I hate the term “Leetcode” as a replacement for data structures and algorithm questions.

I think, the number one reason why people hate Leetcode in interview setting is because of lazy interviews which only took question(s) from the bank, threw it to candidates, and testing whether they can solve the problem or not. Similar to “can a monkey climb?”

TODO: fill the rest

Starts with concrete, tactical, and practical point of discussion. See at the bottom for foundational principles and values.

Recently our team started making smaller PRs and stacking them. Here is my reasoning on justifying why smaller PRs is better than a big(ger) one even with several administrative overheads as mentioned below.

Here are the pros:

• Reduce the chunk of focus block the reviewer (me :smile:) needed to carve out of their time
• Get the PR reviewed faster (and merged faster) enabling faster feedback cycle (and less context switch in-terms of days)

Cons:

• Requires some thinking on how to split the code into reasonable chunks
• PR stacking yield merge conflict

1st cons aint real. Provides better structured thinking and better code isolation and responsibility. In blunt context, reduce the chance of spaghetti code because the stubbed out code provides strong separation of concern needed that just this part of currently implemented code (skeleton code) is sufficient enough to produce good understanding of what is it doing without the underlying implementation details.

Tactical Tips

1. Direction of Change

• You can start bottom-up such as DDL, domain, data layer.
  • Pros: you build from smaller building blocks. So nothing get stub out and everything is concrete.
  • Cons: Sometimes bottom up is hard because the read/write pattern is not clear.
• Can start top-down from Routes + Service:
  • Pros: clear read/write pattern yields more focused responsibility on data layer
  • Cons: stubbed out code, Pagination may be unwieldy to stub

2nd cons is something that I’d trade for the pros listed. Of course it’s biased as it helps me review code faster. But I still think let say just the sake of getting code merged faster is already a plus for everybody. Plus the rest of pros laid out above

2. Separate Refactoring from Features

A common cause of huge PRs is mixing a large refactor with a new feature. The rule should be:

• PR #1: The refactoring. (e.g., “Refactor Service Layer to use new pattern”).
• PR #2: The new feature, built on top of the refactored code.

3. Use Feature Flags

For large, multi-day features, the work should be done behind a feature flag. This allows developers to merge incomplete, incremental PRs into the main branch without affecting users. The 1000-line feature can be broken down into 2–3 coherent, digestible PRs.

Principles & Values

1. Short(en) Feedback Cycle

Short(er) cycle for feedback is fundamentals for developer experience. Getting feedback early enables us to iterate changes more frequently which reduce risks of diverting too far from the correct “line” (note, nobody knows what’s the correct “line“, but we can move in smaller steps in what we think is better that current position).

Short(er) feedback cycle also reduce context switching as PRs get reviewed in 2 days, instead of 4 days later when we’ve moved on to another feature we’re working on with another set of contextual business domain that we need to keep track mentally in our working memory.

This can be achieved by reviewing PRs immediately. But, most of reviewers don’t have a good chunk of 2 hours of highlyfocused block in their day to review a PR of 1,000 lines of reviewable code (includes production, tests, and boilerplate; excludes generated code, dependencies, and large data files). So it’s important for software engineers to be able to split their work into smaller, digestible chunk of PRs with various tactical tips laid out above (Tactical Tips).

https://mtlynch.io/human-code-reviews-1/#start-reviewing-immediately

Based on multiple researches such as SmartBear — best practices for peer code review, reviewer takes about 1 hour per 500 LoC reviewed. Any rates faster than that, it shows a significant drop in defect density.

Reviewer takes about 1 hour per 500 LoC reviewed.

I think the this is understandable and reasonable. What I’d like to propose is the one reason why these hate came up to be are caused by lazy interviewers which I assume they took question(s) from the bank and threw it to the candidate. Test whether they can climb them as expected or not.

I already disliked the term “Leetcode question” itself as a replacement for data structure & algorithm question.

It’s not about whether the candidate can arrive to the finish line or not. Rather, we should be looking at the delta. That is, given starting point and a hard situation, i.e. the question at hand, how far can the candidate arrive at the finish line.

The candidate who has the highest delta should be the one selected. I’d propose the delta as the number one measurement because it reflects the work environment the most. Work setting is about having some problems that needs to be solved in a very dynamic environment. You can do a lot of activities to achieve the goals such as code the implementation, design the solution, do the initial PoC to derisk a project, talk to your manager.

All of those activities cannot be tested in a constrained 45 minutes interviews. So, instead of testing the real activities, opt to test for the existence of the fundamental, core traits that supports the behaviours we would like to see.

The simplest representation I can think of is we can represent the day-to-day activities we do in work as the circles in red. While the circles in blue are the fundamental, core traits that support the activities.

The core essence of data structure & algorithm (DSA) questions are to test the fundamentals of the candidates in hope that it’ll cover enough ground for the downstream day-to-day activities.

But, Leetcode “practicioner” rip out that essence from (DSA) questions and make it so it’s like a tree monkey climbing simulator. It’s like a industrialized version of a hand-made crafts.

There’s also another dimension of the question being “too pure” or too far from the practical skills applied daily.

Hence, conducting these kind of interviews is actually hard. First, the interview skill issue. Second, the nature of question being too far away from practical day-to-day skills.

With all of the context at hand, I would propose a solution for the 2nd problem we have at hand. First, we should understand what’s the requirements for the actual technical skills involved. Second, take one abstraction level higher from that layer of technical skills.

Using the same simplified representation of people activities, skills, and traits, instead of testing for the root nodes which is 2 level away, we test for the circles in blue, which is 1 level away from practical day-to-day skills.

To make it concrete…

Recently we need to hire a frontend engineer with Typescript and React tech stacks. What I asked is React State Tree Traversals of components are represented as tree, how state propagates from top to bottom, calculating final state renders, and updating those states. It’s a simplified version of how React manage states.

I can ask the candidate to implement a website. That’ll take a while, but it’ll test whether they can use React or not. But not much signal besides that. We’re not sure of how far their debugging skills, their thinking capacity, etc.

One abstraction higher on that is testing whether they understood React internal working. How are the states being managed in React? Understand the inner principle, the initial reasoning why it the way it is is crucial on seeing whether the candidate has a strong reasoning skills. Being able to model a tree, doing “mental gymnastic” on the tree test whether the candidate has a strong mental model skill.

TODO: refine