Forem: Frank

Are You Lazy or Burnt Out?

Frank — Sun, 17 Dec 2023 18:29:35 +0000

View a tl;dr on Substack.

Lack of motivation is so commonplace that there’s a multi-billion dollar industry designed to profit off of it.

However, one thing I’ve learned throughout the years is that we all stand to benefit from understanding our physiological and psychological signals. We inherently understand that the correct response to muscle soreness is rest, so why do we not apply the same principles to our psychological indicators?

Traditional grind culture sidelines psychological signals. Emotions and feelings are considered unimportant and productivity is the only concern. This is a great recipe for burnout.

On the opposite end of the spectrum, current day wellness culture is heavily in tune with the need to rest and recover. While this is a positive change, wellness is often used as an excuse to not get work done.

Are you burnt out, or are you just lazy?

My rule of thumb is:

I’m being lazy if I haven’t yet started the task
I’m burnt out if I’ve been spending 80%+ of my available time on the task

For the latter item, “available time” is loosely defined and entirely dependent on the task itself:

For a work-related task, then “available time” would be the amount of time I’ve allocated towards that piece of work
For something like writing a blog, “available time” would be the amount of time I dedicate towards hobbies

There exists a spectrum of states in between these extremes, and it’s up to you to develop an intuition for identifying the root cause of your lack of motivation. As an example, I may have been extra busy at work - potentially putting in 80+ hours a week into my startup. If I end up unmotivated to write a blog post, I’ve come to understand that:

I’m burnt out because my mind has been mentally drained from work
I should take my free time to rest and recuperate - not further tax my brain by trying to write a blog

Having an understanding of your psychological state allows you to take the best course of action in response. The best remedy for burnout is to distance yourself from stress and engage in activities that rejuvenate your mental well-being. But if you’re just being lazy, you need to swallow your emotions and just do the damn thing.

The Optimal Engineering Culture

Frank — Sun, 03 Dec 2023 20:56:59 +0000

View a tl;dr on Substack.

For a tech company, engineering culture is integral to the lifeblood of the organization. These cultural norms have both short and long term impacts, and starts forming at the early stages of organizational growth.

I’ve worked on two extremes of engineering culture:

In an organization where technical excellence is revered: There was a strong focus on writing scalable and maintainable code, sometimes at the expense of velocity. Engineers had authority over product decisions. Features that required unsustainable workarounds were often reworked or scrapped entirely. This resulted in a codebase that was extremely robust and a generally happier engineering team. However, product development was noticeably hindered by the focus on technical excellence.
In an organization where velocity is king: The company was made up of many small teams that operated like individual startups. While this was exhilarating in many ways, maintainability was often deprioritized for the sake of velocity. This resulted in a flaky codebase with poor dev tooling.

At my current startup, I have significant authority over both product and engineering. which means that I’m in a unique position to establish a cohesive engineering culture within the company.

So the question is - what’s the most optimal culture for the company to thrive?

While I don’t have the definitive answer, what I do know is that there is no one-size-fits-all culture that reigns supreme over the rest.

Culture evolves as the company grows. When the product is in its infancy, speed is of utmost importance. The goal of the organization is to move as fast as possible to achieve product market fit. This is the time to move fast and break things. During this stage, it’s okay to have “hacks” to achieve some product objective if it means a faster time to market.

However, this is not an excuse to be sloppy. It’s important to understand the shortcuts that were taken and compile a list of items that should be revisited if the product grows past infancy.

I also believe that product infancy is the only time where sloppiness is acceptable. In my opinion, engineering excellence paves the way to a scalable product and a happy organization. As the product matures, it’s important to create an environment where code quality is prioritized. This means:

Structuring incentives to promote code quality and encourage development of internal tooling
Consciously cataloguing and addressing technical debt
Communicating with product / design to create a feature roadmap that is synergistic with engineering excellence

Having a team that is focused on writing high-quality code means that the product is resistant to breakage. Moreover, high technical standards pave the way to better internal tooling and decreased developer mental load, ultimately leading to a happier workforce.

The alternative perspective is that an organization should optimize for user impact. At the end of the day, code is written to solve a user problem, and the quality of that code is sometimes uncorrelated with the user’s quality of experience.

I would push back on this perspective on several fronts:

Poor code quality ultimately means increased downtime and higher probability of bugs, leading to poorer user experience
The organization also needs to serve its employees. Higher quality code and better internal tooling translates to happier and more productive developers

However, I do recognize that there is a spectrum of ideal engineering cultures, where one end optimizes for technical excellence and the other prioritizes user impact. The true ideal varies depending on the organization and the product that it serves, but understanding the trade-offs is a pre-requisite to establishing a culture that serves all stakeholders of the company.

The Importance of Slack

Frank — Sun, 26 Nov 2023 21:26:01 +0000

View a tl;dr on Substack.

Traditional productivity advice attempts to optimize for amount of work done, with the goal of:

Increasing the number of work blocks in our schedule
Increasing the number of to-do items you accomplish in a day
Decreasing idle time

Idle time, or “slack”, is often viewed as wasted time. Productivity gurus recommend carefully planning out your day in rigid blocks. This applies not just to your workday, but also your personal life.

I recall one extreme example, where a productivity Youtuber mentioned that he schedules weekly date night on his Google Calendar (a few hours on a Thursday, if you’re curious).

This is absolutely ridiculous. We need slack in our lives - not just for the sake of sanity, but for the sake of sustainable productivity.

Granted, I’m not perfectly shielded from the urge to set a rigid timetable. I have always been one of routine, aiming to optimize everything I do. But more recently, I’ve been forcing myself to increase slack in both my work and personal lives. I have found that having more idle time and less rigidity actually increases productivity and greatly boosts mental well-being.

When you live by a rigid schedule, your mind is focused on satisfying self-imposed time constraints as opposed to being immersed in the present task. This creates a persistent anxiety about living your day as it was planned on your calendar. Small inconveniences then end up creating large problems. A simple 5 minute delay can wreck your schedule and leave you feeling frustrated and irritable.

Rigidity and lack of slack works extremely well provided nothing goes wrong. But the chances of nothing going wrong is slim to none. The world is uncertain and we cannot pretend that we can fully shape our future through back-to-back blocks on a calendar.

So, what’s the alternative? My way of life is far from perfect, but here are some things that I’ve implemented.

#1: Build a priority list of tasks to start the day

This is really no different from traditional productivity advice. My day falls apart if I don’t begin with intention. I create a list of everything I need to do for a given day and force-rank by priority. I try to categorize my to-do list into three buckets:

Must do: this needs to be done today, no exceptions.
Should do: it would be ideal if I could tick this off, but it’s not the end of the world if it isn’t done.
Do if able: low priority tasks that I can pick off if I have the time and energy.

I’ve found that the majority of tasks end up in the “should do” pile. We often stress ourselves out by creating impractical self-imposed deadlines, but few tasks are as urgent as we think they are.

#2: Intend on productivity, but avoid commitment

Introducing slack is by no means the same as introducing laziness. I still aim to accomplish as much as I can within a given day, but I am no longer a slave to my schedule or my to-do list. Of course, scheduled meetings and appointments are unavoidably rigid, but all other hours of the day remain flexible.

My mission for a given day is to:

Finish everything in the “must do” list
Make as much progress as possible on “should do” items and complete “do if able” items if the time allows
Embrace the spontaneity and uncertainty that is inherent to life

I’ve stopped committing to finishing tasks that are not absolutely critical, but this does not mean that I view them as any less important. This means that I’m better able to mentally handle the normal disruptions of life. I’ve found that this shift in mindset has freed up mental bandwidth, making me more productive than I was before.

#3: Embrace incompleteness

I used to view each incomplete task as a failure, but I’ve come to realize that this is irrational given that:

More often than not, the task deadlines are self-imposed
The day is uncertain, and setbacks are unavoidable
The length of my to-do list is influenced by external, uncontrollable factors

My new perspective is:

If I’ve completed everything that I “must do,” then my day was a success
It’s absolutely okay to end the day with incomplete tasks
These tasks form the basis of my priority list for the following day, where I repeat the cycle from item #1 (creating a new priority list)

While it might seem easy to implement a “lazier” lifestyle, I found it extremely difficult to detach from my natural impulse to live a highly structured and fast-paced life. I’ve been practising these 3 principles over the past year, yet I still suffer periodically from “incomplete task anxiety.”

Compared to a year ago, however, I’ve found that I’m much better at dealing with the natural unexpectedness of daily life. I’m happier, more carefree, and a better person to others. And the craziest thing? I’m more productive than ever.

Maintaining Velocity Amidst Complexity

Frank — Sun, 19 Nov 2023 17:58:05 +0000

View a tl;dr on Substack

As a startup grows, complexity grows with it:

With more and more engineers working on the same codebase, you no longer have complete control over the code that gets shipped.
A more sophisticated product means a more interconnected web of services, schemas, and external dependencies.
More users and stakeholders mean that you now have to solve for an increasing number of different preferences.

Whether it be launching a new product line or raising another round of fundraising, your ability to embrace this complexity is critical to maintaining velocity within a startup. Here are some things that I’ve found works well.

1 Hire & train the right people

Technical founders have a tendency to want to do everything themselves. This works well for an early-stage company, where complete ownership means fast execution and holistic understanding of the product.

However, as the company and the product grows, trying to maintain complete ownership is a recipe for burnout. Instead, founders that scale have key delegates that they trust to own a particular organizational/product domain.

A startup’s first hires are critical. You want to enlist intelligent and self-driven individuals that can eventually grow to take partial responsibility of the company. Additionally, it’s important to invest time and energy into onboarding and training these hires. It may be tempting to do something yourself because it’s easier and faster, but allowing your hires to struggle with tasks of increasing scope is an important part of their learning process.

Without the right people, even the most robust processes will fail to drive results.

2 List and delegate dependencies

When embarking on a new initiative, you must first define what exactly you are trying to accomplish. It’s important to ask the following:

What are all the things that need to happen in order for us to succeed?
What is the order in which these tasks need to occur? Which tasks are interdependent?
Who can take full responsibility of these tasks?

Start from the end result and start tracing the dependency tree back to the current day. This will allow you to create a list of tasks that act as a high-level roadmap.

Then, delegate these dependencies to the people best suited to take responsibility.

3 Have frequent check-ins

With items 1 and 2, you will have created a plan and assembled a team to execute on that plan. However, the entire process can easily fall apart without a leader to act as a lubricating mechanism to the cogs of an organization.

Touchbase with stakeholders regularly to understand progress and adjust timelines as needed. These check-ins are also good opportunities to realign priorities and address blockers. Answer key questions, such as:

What has the team been working on since the last sync?
Is anyone experiencing any blockers on their progress?
Does anyone have concerns about the success of the project deliverables and timeline?

While async workflows can be great for this, I find that a weekly synchronous call does wonders for team cohesion.

The ability for you to execute a complex project ultimately rests on:

Having the right people to take responsibility
Proper planning to ensure all dependencies are met
Regular check-ins to update progress and revise projections

These might seem painfully obvious, but it is one thing to understand how to do something and another to actually to do that thing properly. The best leaders have a plethora of experience in past projects, both successful as well as not, from which they gain an intuition for managing complexity.

Software Dev is a Drug

Frank — Sun, 12 Nov 2023 18:31:54 +0000

View a tl;dr on Substack

I vividly remember having a 1-1 with a past manager who was taking an extended period of time away from work. When asked about what he planned on doing during his vacation, he replied: “I want to experiment with SwiftUI for iOS app development.”

Writing code is one of the few professions where people spend their free time writing more code. This observation has always been puzzling. One would think that after 40+ hours of staring at a computer, the last thing someone would want to do is to continue ruminating over lines of code.

Why is this the case?

In many ways, software development piggybacks on the same addictive mechanisms that make social media and recreational drugs so appealing.

Feedback loops in software development are insanely fast. In more “traditional” mechanical / electrical engineering, it could take months (if not years!) to create a prototype from an initial idea. With software, it could be a matter of hours (if not minutes!). This creates an endless flow of dopamine hits, not unlike the feedback loop of mindlessly scrolling TikTok for the next interesting video.

Creating a solution through code is rewarding, yet often uncertain. You don’t know for sure whether a specific change will fix a bug, or whether your code will compile after 30 minutes of hard work. This uncertainty, when paired with periodic success, is a powerful motivating factor. The phenomenon is termed the “unexpected rewards principle” and is well-known within human and animal psychology.

And lastly, we know too well the satisfaction of achieving “flow” while coding. While incomparable to cocaine-induced euphoria, the allure of effortless productivity is undeniably attractive.

If software development is so addictive, then perhaps we should treat it with the same level of caution that we do with any other indulgence.

I’ve come to realize that it’s important to be mindful of the time that I spend developing software. By clearly defining my boundaries and finding hobbies unrelated to my profession, I’ve not only become happier, but also more productive during my time spent writing code.

Effective Code Reviews

Frank — Sun, 05 Nov 2023 23:17:52 +0000

View a tl;dr on Substack

Being able to effectively review code is one of the most difficult tasks to master as a software engineer. Auditing someone else’s code requires an individual to derive and understand someone else’s mental models. To make matters even worse, these mental models are often scarcely explained and riddled with bugs.

As a result, code reviews are often poorly done, or ignored altogether.

This post will cover the general characteristics of a good code review. With this knowledge, I hope that you are better able to contribute to your team & organization by being a helpful & effective reviewer. In future articles, I will be covering strategies that I have discovered through experience to make reviewing code easier and less unpleasant.

Effective code reviews identify potential errors in logic

I’m a firm believer that a code merge is the dual responsibility of the author and the reviewer. Identifying erroneous and/or dangerous code should be the reviewer’s utmost responsibility. Ensure that you have full context over the changes that are being introduced, as some bugs are not apparent unless you have a good understanding of the business logic / software design of the changes. If you don’t have full context, ask a team member that does. Remember, your team is here to help!

Effective code reviews suggest optimizations in logic, efficiency, and readability.

Your goal as a reviewer is to propose better ways of doing things. This could be one of the following:

Identifying unnecessary logic. For example: “You’ve already done this check above on L21, so we don’t need to do it again here”
Improving code efficiency. For example: “We can reduce the time complexity from O(n^2) to O(n) by doing X.”
Making things more readable. For example: “Instead of using a nested ternary, can we split up the conditions to make the logic more understandable?”

Effective code reviews enforce organizational conventions

There are multiple ways to write code, and each of them can be equally correct. Just as authors have their own literary style, developers often write code in slightly different ways.

However, a consistent codebase is more debuggable and comprehensible. As a reviewer, you should understand organizational patterns and identify deviations from those patterns. For example:

Identifying an existing utility function that could be used instead of an inline implementation
Highlighting deviations from a team-wide style guide
Suggesting usage of standardized software design patterns

Effective code reviews expose developer assumptions

As a developer, you create mental models to decompose a complex problem and construct a suitable solution.

As a code reviewer, you often do not have access to those mental models. This is largely why reviews are so mentally draining, but it’s also why external code reviews are so useful to maintaining the readability of a codebase.

A piece of code should be comprehensible to an external reader without execution. This means that the logical flows introduced in a PR should be understandable without you having to run the code. Your job as a reviewer is to expose developer assumptions that have not been communicated properly.

Ask questions as you read the code, such as:

“What did you mean by the comment on L34?”
“Why did you use util X instead of util Y?”
“Was there a reason for adding such extreme retry logic?”

These questions then serve the basis for:

Uncovering bugs
Identifying clarifications that should be added as code comments
Exposing potentially incorrect assumptions that don’t align with the feature being developed

Effective code reviews don’t waste time

One of the biggest mistakes that a reviewer can make is to be overly critical of things that don’t matter. Organizational conventions aside, it is not your job as a reviewer to rewrite the code as if it were your own.

Developers have limited mental bandwidth. If 90% of your comments are nits, then you’re severely reducing the ability of the code author to address the items that actually do matter.

(Not to mention, you’re likely annoying the hell out of the author!)

Being a thoughtful reviewer is one of the most important ways you can contribute to your team and organization. I hope that the insights outlined above can serve as a set of north star guidelines for your next code review.

Mastering the Art of Rest: Strategies for Sustainable Productivity

Frank — Mon, 30 Oct 2023 04:33:57 +0000

View a tl;dr on Substack

Working for the sake of being busy is a great way to achieve burnout as fast as possible. While being part of a startup requires a time commitment that far exceeds that of a full-time job, it’s dumb to assume that your body & mind can work every hour of the day without losing effectiveness.

We all crave the “flow state,” but how often do we end up staring at our screens and getting nothing done?

If you ever catch yourself zoning out, chances are that you need to abandon what you’re trying to do (work) and instead focus on the inverse (rest).

And if you feel unproductive often, chances are that you need to take an extended period of time off to recharge.

But rest isn’t created equally:

Unproductive rest leaves you feeling lethargic and unmotivated.
Productive rest allows you to recharge and become reinvigorated.

We obviously want to do more of the latter and less of the former. Popular convention will attempt to categorize certain activities as being “good rest” and others as being “bad rest,” but I’ve come to realize that there is no clear dividing line.

As with your diet, the dosage makes the poison:

Drinking water is great for you, but not if you ingest multiple gallons in a few minutes
“Dirty” food can actually be a great way to replenish glycogen stores if you’re cutting weight quickly
Similarly, certain activities can be very healthy for productive rest, but only when done for a short period of time. For example, I’ve actually found that mindless scrolling on social media, when constrained to a few minutes, can actually be very useful if I’ve been working on a mentally challenging problem.

As such, I’m not here to categorize activities as “good” or “bad.” I’m simply here to share the things that I personally do to recharge based on the time that I have.

Short Form (5-30 min)

Social media: I find that just a few minutes of social media gives my mind a quick break from brain-intensive work. Use this with caution and avoid longer periods of mindless scrolling. Sometimes all I need to re-motivate myself is a few quick dopamine bursts.
Stretching / mobility exercises: A quick break to do some yoga (or even just a few cat-cow’s) is great for getting the blood flowing.
Zero distraction meals: Cooking and eating a meal without checking Slack or social media is a nice way to quickly detach from technology.
Chores: Doing a chore is a great way to trigger a small dopamine hit for completing the task. I do this when I’m stuck on a particular problem and feel unmotivated to push through.

Medium Form (a few hours)

Exercise: Doing some form of exercise, such as going to the gym or going for a walk, allows you to reconnect with your physiological self. I get the most benefit if I avoid my phone while doing so.
Reconnect with a friend: Plan an activity with a friend and spend some time socializing. It could be as simple as just having a chat over coffee.
Work somewhere else: I find that changing my work environment resets my energy levels. I leveraged this a bunch in university by switching between the library and different cafes.

Long Form (Multiple Days)

I think the most obvious idea here is to go on a trip somewhere for a change of scenery. I unfortunately don’t have the ability to do this often, but my favorite getaways are to small towns surrounded by nature. I’ve also been tempted to do an extended yoga/silent retreat, but can’t comment on their effectiveness.

That being said, I’m definitely more of an outdoorsy person, so choose a destination that works for you.

The activities I mention above are my go-to ways to take productive breaks away from work. Everyone is different, so your mileage may vary. A great way to identify your own strategies is to be conscious of how different activities influence your motivation and energy levels.

I want to end with a note of caution. I think we’re often far too concerned about optimizing our lives. It often works best to let go of the need for perfection and embrace your desires of the moment.

Lead Teams, Not Lines of Code

Frank — Sun, 22 Oct 2023 19:51:53 +0000

View a tl;dr on Substack

Managing people is nothing like writing software. Code is often binary - it either works or it doesn’t. People are messy - they are undecipherable globs of emotions and desires. Developers thrive when given focus time, but effective management requires constant collaboration and connection.

The career ladder for a software engineer usually involves climbing up to a managerial role, but the requirements for an engineering manager are distinctly different from that of a developer.

This transition is difficult to make, and isn’t meant for everyone. Good engineers aren’t necessarily good managers. If you don’t want to spend your work-life dealing with people, then consider a more technical role (such as a principal SWE).

During my time in a management role, I’ve screwed up many times and learned something from each of those failures. I’ve distilled my mistakes into 3 major themes.

Mistake #1: Being an engineer

I hinted at this already above, but management != engineering. Contrary to popular opinion, engineers aren’t logical robots: They are human. This means that:

They are irrationally driven by their own goals & desires.
They have their own private social / family lives.
They are imperfect communicators.

You are going to fail if you approach management like an engineering problem. The better you become at understanding the influence of human psychology on behavior, the better you’ll become at leading a happier and more productive team.

A lot of this comes from experience, but it also helps to peruse popular books on human psychology.

Mistake #2: Giving too much autonomy

To be promoted into a managerial role, you are likely skilled in your craft and have a high level of motivation. Don’t assume the same of your coworkers:

Identify team members who need more supervision. Especially in a remote/hybrid workplace, it’s important to set goals and deadlines with these individuals.
Identify team members who need more technical guidance, and make sure they have the help they need to unblock their work.
Identify team members who function best when given autonomy, and shift your focus away from them so that they can operate in a way that works best for them.

Mistake #3: Not protecting your own time

I mentioned at the start that a manager spends most of their time collaborating and connecting with others. This doesn’t mean that you cut out all focus time. Especially at smaller companies, managers are also expected to be developers. In fact, engineering managers are sometimes the ones championing the most complex of projects.

You need to be ruthless about prioritizing your own work. Some things that have helped are:

Block out focus time for yourself in your calendar, during which you prioritize your own work over assisting others.
Ensure that your coworkers have multiple tasks in their backlog, this means that they can always switch to something else if they are blocked.
Consciously muting notifications / using focus mode / quitting slack & email so that you can create a quiet environment.

It's okay to screw up

Becoming an engineering manager means that you have exceeded expectations, but it also means that you're now in a position to fail.

Learning to manage people instead of lines of code is no easy task, but I hope that you can avoid making many of the same mistakes that I have during the process.

Ignoring and trying to explain away your screw-ups is a fast track to failure. As much as it hurts, embracing and analyzing your mistakes is the only way to become better at this new craft. Success isn't about being the best leader out there, it's about being a better leader than your past self.

On Great Product Managers

Frank — Sun, 15 Oct 2023 04:33:31 +0000

View on Substack

Ex-engineers are some of the best product managers.

Some of them transitioned into product because of a desire to try something new, but most of them transitioned because they weren’t superb engineers.

There’s nothing wrong with being an average engineer, but there’s definitely something wrong with staying a path that wasn’t carved out for you. I applaud those who have made the switch.

Ex-engineering product managers are creative and empathetic. They might have initially entered software because of their desire to solve problems in an ever-digital society. However, they typically don’t follow the stereotype of the “don’t talk to me while I code all night” programmer. They relate more with user problems, and have a desire to work with various stakeholders to solve those problems. As a result, they don’t tend to stay in a traditional SWE role, where the opportunity to talk to users (especially at large corporations) is few and far between.

Being an ex-engineer has benefits that can’t be easily taught to your run-of-the-mill product manager. Engineers are taught (whether in school or through experience) to think logically and build solutions through first principles thinking. This ability allows a product manager to decompose a seemingly insurmountable set of different requirements into digestable chunks that can be fed through the product pipeline.

The experience of working as an engineer is also important. This allows a product manager to emphasize with the engineers and understand why certain feature requests are not feasible

At smaller companies, product managers may be in charge of design. Engineering experience enables a streamlined relationship between dev and design: ex-engineering product managers can immediately see potential issues in implementing a design proposal, and address them with the designers before it ever reaches the eyes of an engineer.

In short: Product managers operate at the intersection of design and engineering. They must be able to identify and solve user problems, but also understand and work with engineering limitations.

To engineers considering a switch to product: know that you have a unique advantage and leverage it as much as possible.

To product managers without an engineering background: know that all hope isn’t lost. You can learn to think of an engineer by:

Seeking feedback often from engineering
Understanding and incorporating said feedback into future work
Being constantly curious about how software development works (perhaps even learning some programming yourself!)

Hello World

Frank — Fri, 06 Oct 2023 17:56:14 +0000

View on Substack

I’m your average mid-twenties software engineer whom, in the past couple years, managed to find himself in a director of engineering role at a crypto startup.

My personal hobbies have nothing to do with tech. I love to do anything & everything active. I’m an avid weightlifter and try to mix things up from time to time with boxing and hiking.

Today, I decided that I want to start a blog.

The Why

I generally don’t like to read articles related to software / tech. I find that existing content typically have low information-to-word ratios. This blog will attempt to challenge the status quo by attempting to deliver the most information in the fewest words possible.

That’s the value prop for you, the reader. However, I’d be lying if I were to say that this blog serves me no benefit. You can freely skip the rest of this section if you don’t care.

As someone who manages multiple people in a fast-moving startup, I’m bombarded with inputs and spend my days making decisions for myself and on behalf of others. I characterize this as “high frequency” work. Taking time to write these blogs is an opportunity for myself to consolidate my thoughts and derive insights from my otherwise hectic life.

To help achieve this goal, I’m taking the opposite approach from the content writers of the post-ChatGPT world by not consulting AI for content. The only exception to this rule is the AI-generated tl;dr’s that I will include with each article, which is done only as an experiment to see the evolving summarization capabilities of the latest LLM’s.

The How & What

This isn’t going to be a “tutorial” based blog. Nor is this going to focus on a particular realm of software engineering. Expect an amalgamation of:

Deep-dives on technical topics across the software engineering stack (on anything from mobile to smart contract development)
Reflections on my experiences with team management and product strategy (specifically in the crypto space)
General thoughts on the state of the industry and cutting-edge technology

I want each article to be insightful (so that you benefit by gaining knowledge) but never drudgingly academic (so it doesn’t feel like you’re reading a textbook).

That’s a Wrap

If you’re reading this soon after the article is published, then I hope that you’ll come along for the ride. If you’re reading this in hindsight, then I hope that this gives you insight into my motivations and thought processes 🙂.

See you in the next one.